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

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


Сообщения - valexey_u

Страницы: 1 2 [3] 4 5 ... 201
31
Попробовал через FIO, получил
this file (input) was not successfully opened.
Стоп. А у тебя какая система с gm2? 32 или 64 бита?

Ибо по коду FIO.mod выходит, что такое может быть только если юниксовый open вернул -1.

32
в С# через рефлекшн это конечно можно сделать, но преимущество будет не то.

хочется не рантайм.  А даже вот такое через приведение типов Mask m = (Mask)a;
Только всё это повлечет большую вероятность сделать ошибки, а этого надо избегать (не давать технической возможности делать ошибки)
Погоди, тебе хочетяся плюсовых концептов да хаскельных type classes что ли? Т.е. хочется штуку которая к ООП вообще отношения не имеет.

33
Оказывается, xds под линуксом не умеет работать с файлами > 2GB :-(. Программы просто падают при первой же попытке чтения.
И у gm2 такая же фича, по крайней мере с библиотеками ISO.
А как они падают? Говорят что? Судя по всему оно не умеет работать с файлами >=2Gb - тесты же проваливаются начиная с 2Гб файлов.

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

35
А если объектег не может то, что маска хочет? Что будет?

36
В общем, дальше планы такие: я сейчас запущу пятикратный прогон теста. Потом, если кто-то будет обновлять/исправлять/добавлять решения я буду делать новые прогоны. С системе тестирования по крайней мере до понедельника никаких изменений не будет, не будет и каких-то решений от меня.

На следующей неделе (а если не уложусь, то и через неделю) я хочу допилить визуализацию результатов тестирования (очевидно, что текущий вариант не достаточно нагляден для случая когда у нас много разных решений), плюс добавлю дополнительные тесты а также модифицирую своё решение и добавлю ещё одно своё.

Потом хочу попробовать так или иначе найти ещё участников соревнования :-) Если никого больше не найдется, то будет финальное тестирование и подготовка к фазе 2.

37
Ну вот тест на 2Гб файле, первая колонка - с большой дисперсией, вторая колонка - с малой (массив одинаковых значений).

comdiv hardcore:
2048 458.21    32.54
comdiv hardcore-single-temp:
2048 127.72    74.92
elektrybalt merge_qs:
2048 failed    failed
elena files_merge:
2048 588.93    481.45
elena linux_mmap:
2048 194.04    104.73
valexey sortix:
2048 285.63    30.70
vlad fast:
2048 141.40    66.23
vlad simple:
2048 606.04    499.26
vlad multi-threaded:
2048 279.11    147.41

38
Это не для моего :-). Мне кажется bucketsort с фиксированными корзинами должен на таких задачах страдать.
Ну, это я отвлеченно говорил :-)

39
Интересно, а срди тестов есть распределения с малой дисперсией?
скорее всего пока что нет. но всё будет :-) если для вашего алгоритма существует наихудший набор данных, то он будет среди тестов. :-)

40
Результаты готовы.

41
А после того как собрали, многопоточка выходила за ограничения по памяти, а после фикса этого выдает не верный результат (размер файла не верен).

Фикснул. Как я и предполагал - непрваильно поток прибивался, до того как он успел файлик записать :)
С памятью интереснее - у меня не получилось выставить ограничение (процесс не прибивается, если много отжирает).
Через час-два будут результаты очередного быстрого прогона.

42
А после того как собрали, многопоточка выходила за ограничения по памяти, а после фикса этого выдает не верный результат (размер файла не верен).

43
Да, а многопоточное решение по производительности не отличимо в этом тесте от однопоточного.

Что очень странно. Единственное объяснение, которое я могу придумать - все уперлось в диск. А наблюдаемая разница на моем нетбуке - это потому что проц совсем дохлый.
Открыта тайна третьей планеты!

В смысле, я нашел в чем была засада - многопоточное решение не смогло слинковаться, в итоге вместо него тестировалось обычное fast (да, скрипты тестирования писал я, и у меня крайне кривые руки). Сейчас пофикшу.

44
Да, а многопоточное решение по производительности не отличимо в этом тесте от однопоточного.

45
Готовы новые результаты. Есть новый самый быстрый алгоритм - от comdiv'a (comdiv hardcore-single-temp) а алгоритм на modula-2 merge_qs выдал не верные результаты на больших файлах:
elektrybalt merge_qs:
128 18.30
256 38.12
512 76.50
1024 154.81
2048 failed
4096 failed

Страницы: 1 2 [3] 4 5 ... 201