Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - kkkk

Страницы: [1] 2 3 ... 9
1
Общий раздел / Re: Online компилятор Oberon-07/11.
« : Март 31, 2019, 02:19:08 am »
Что Вы хотите поправить? Если добавить внятности ошибки, то можно, но вряд ли автор транслятора будет это делать. Если возможность использовать открытые массивы в записях, то нет - это не соответствует языку.

2
Имя тэга после ключевого слов struct должно отличаться от имени, задаваемого "переменной"-типом через typedef, так как в С++ это способы определения синонимичны, а в С - нет. Поэтому в Си компилируется без проблем, а в С++ это повторное задание идентификатора в той же области видимости

3
Какие выводы? Умение писать алгоритмы позволяет писать более эффективные решения, чем умение пользоваться стандартными библиотеками. В некоторых случаях сложность использования библиотек может быть на уровне или превышать сложность написания алгоритмов.

4
Выглядит сурово, но судя по названию, это простое решение. Хотелось бы поглядеть на сложное.

5
Да, я не обратил внимание, что длина указана для массива 32 разрядных чисел, а не для байт. Тогда странно, что сортировка не самая быстрая, возможно, что это слабость компилятора или недочёт в библиотеках.
Поразрядная сортировка работает быстрей быстрой, поэтому на закэшированных файлах оказывается лучше, но из-за удвоенных требований по памяти приводит к увеличению временных файлов, что, по видимому, и приводит к перевесу быстрой в условиях ограниченной памяти.

6
Смотрю на SSD ввод/вывод намного дешевле, чем на HDD. Эффект от сжатия слабее.
Идея, в целом, верная, но не доведена до конца. Если увеличить до упора размер входного буфера, это может изменить расклад.

7
Цитировать
Допустим имеется два класса несвязанные между собой базовыми наследованием, применяя к ним маску мы получаем доступ к одинаково именованным методам и свойствам, которые соответствуют маске.
Так сделано в Go. То, что Вы называете маской, в Go называется всё-таки интерфейсом. Чтобы соответствовать интерфейсу тип должен воплощать методы интерфейса, но явной связи(наследования) не требуется. Единственная разница с Вашими масками в том, что из интерфейса доступны только методы, но этого достаточно.

8
Как Вы это ограничение выставляли?

9
Ещё замечание 4 минуты да и 1 минута - это очень мало. Такое ощущение, что у тебя весь файл поместился в ОЗУ (в дисковый кэш системы).
Насколько можно судить, решения считывают огригинальный файл один раз, а делается это быстро, но есть, конечно, и временные файлы, это может сказываться.

10
Для конкретной программы? Тогда - да.

11
Практически доступное ОЗУ при этом система сама использует под кэш диска. Ну, т.е. такая масштабируемость штука идеальная на самом деле.
Не идеальная, потому что часто нужно ограничить ресурсы для конкретных программ, оставив их для более приоритетных.

12
Для этого и были созданы скрипты, чтобы каждый мог проверить ещё и проверяющего

13
Ага, временно - хорошо.

Создал 4-гигабайтный файл и сделал прогон для наиболее быстрых решений:
comdiv/hardcore
real 1m25.488s
md5sum = e6d6ad0bad107695536bf8bef475f9eb  output

vlad/fast
real 4m9.742s
md5sum = e6d6ad0bad107695536bf8bef475f9eb  output

Интересное кино получается

14
Результат прогонов для 2-х гигабайтного входного файла
comdiv/hardcore
real 0m36.022s
output md5sum = fa1637b627029ab0566230d3ef11ac1e  output

elena/files_merge
real 5m4.276s
output md5sum = fa1637b627029ab0566230d3ef11ac1e  output

elena/linux_mmap
real 1m19.969s
output md5sum = fa1637b627029ab0566230d3ef11ac1e  output

vlad/fast
real 1m37.925s
output md5sum = fa1637b627029ab0566230d3ef11ac1e  output

vlad/simple
real 4m43.026s
output md5sum = fa1637b627029ab0566230d3ef11ac1e  output
elena/files_merge работает вроде бы медленно, но на самом деле весьма хорошо, потому что потребляет мизер памяти.
elena/linux_mmap работает быстро, но без искусственных ограничений отожрало 4гигабайта памяти

Отсеиваем медленные и прожорливые решения и делаем 2-й прогон:
comdiv/hardcore
real 0m33.318s
md5sum = fa1637b627029ab0566230d3ef11ac1e  output

vlad/fast
real 1m13.470s
md5sum = fa1637b627029ab0566230d3ef11ac1e  output


15
Поскольку из результатов прогона исчезли действительно большие файлы (временно или навсегда?), стало интересно самому сравнить решения на своей системе именно для больших файлов, благо у меня тоже стоит SSD. Для автоматизации были написаны скрипты:

загрузка тестов:
git clone https://github.com/valexey/bigbench.git
cd bigbench
D=( comdiv/hardcore elena/files_merge elena/linux_mmap vlad/fast vlad/simple )
cd comdiv; make; mv vostok ../../; cd ..
for i in ${D[*]}
do
cd $i
./build.sh
cd ../..
done

создание input:
time dd if=/dev/urandom of=input bs=1M count=2048

прогон тестов:
D=( comdiv/hardcore elena/files_merge elena/linux_mmap vlad/fast vlad/simple )
for i in ${D[*]}
do
echo $i
time bigbench/$i/sort
md5sum output > `basename $i`.md5
echo -n "md5sum = "; cat `basename $i`.md5
rm -rf output swap.* *.TMP temp[12] output.temp
echo; echo
done

Страницы: [1] 2 3 ... 9