31
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 06, 2016, 06:54:36 am »
Я сравнивал суммы чисел - такая упрощенная статистика.
Новости:
Онлайн компилятор Oberon-07/11
Путеводитель по Оберон-проектам.
Логи jabber-конференции.
Онлайн исходники BlackBox: тут:WeBB и на github
Исходники Project Oberon V4 на github.
Сборник решений задач книги "Современное программирование с нуля!" тут. А обсуждение здесь.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
32
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 04, 2016, 07:19:34 am »Ага, у меня 32-битная система. Видимо ncurses стоит по умолчанию, или mc подтянул.Код: [Выделить]$ ./xc
./xc: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
$ ./xm
#RTS: Coroutines initialization fault 3...
Можно предыдущую версию XDS (2.51) попробовать, там компилятор статически слинкован.
33
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 03, 2016, 10:06:35 pm »Дык у меня сам компилятор не запускается - ему тоже ncurses нужен...Ктороый, xc или xm? У меня xc нормально запускается, а xm падает что-то там про COROUNITES пишет.
34
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 03, 2016, 08:50:46 pm »Есть 32битный xds (но там надо победить ncurses либу - компилятор требует для работы какую-то древнющую версию).Попробовал сегодня, там надо просто удалить -lncurses из xc.tem - он его лепит ко всем программам.
Хотел написать переносимо, но оказывется в стандарте ISO нет функции удаления файла.
А еще между делом выяснилось, что FAT32 может быть в 2-4раза быстрее, чем NTFS.
35
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 08:11:09 pm »Ну, WinAPI в *nix'ах нет :-) А что сейчас модно использовать вместо Files?Так в *nix'ах и ББ нет официально. Но там же есть системные вызовы и libc.
А вместо Files обычно используют Files.
Для обычной-то работы нормально.
36
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 06:50:24 pm »Кстати, я правильно понимаю, что BB не может файлы больше двух гигабайт?Через Files нет. Но WinApi никто же не запрещает. А Files все равно для таких задач не стоит использовать.
37
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 06:40:54 pm »
Да, а на модуле можно написать? В смысле, будет чем скомпилировать?
38
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 06:39:44 pm »
Есть, но они совсем слабенькие.
39
Общий раздел / Re: Oberon-07/11: Замечания по результатам использования.
« : Декабрь 02, 2016, 06:38:10 pm »Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...Это да. Наверное поэтому в Обероне Shift был без указания направления.
Но ведь аргументом может быть и переменная. И все равно ситуацию с LSH(x, -3) придется как-то разруливать.
40
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 06:24:04 pm »
Не, не пойдет. 32-битная версия не справится, а 64-битная стоит невменяемых бабок.
41
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 02, 2016, 04:58:41 pm »Если на вашем языке нельзя написать функцию сортировки, ну тогда я не знаю..Почему нельзя? Можно.
Код: [Выделить]
sort:{x: |:'(-1 4)#6: `input; `output 6: ,/|:'x[<x]}Только как это переписать на си 
42
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 01, 2016, 08:46:04 pm »
Языки разные но компилятор один. И алгоритм тот же.
43
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 01, 2016, 08:38:56 pm »
На плюсах с std::sort.
44
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 01, 2016, 08:30:07 pm »
Так есть уже.
45
Общий раздел / Re: Расширенный тест на производительность.
« : Декабрь 01, 2016, 07:40:48 pm »
Вот в этих фазах, особенно в последней, смысла совсем не вижу.
Тут еще подумалось, вот в q есть встоенная функция, умеющая быстро сотрировать большие файлы. Если вдуг оказалось бы, что она быстрее всех представленных, как бы ее переписывалт буква в букву?
Насчет std::sort тоже не уверен в данных условиях (кстати, почему qsort тем более? Это же одно и то же практически). Но во времена, когда 640K хватало каждому, забавлялся с сортировкой. Лучшие результаты получались как раз с quicksort. Тогда приходилось сложную схему пейджинга городить, а сейчас можно просто замапить файл.
Тут еще подумалось, вот в q есть встоенная функция, умеющая быстро сотрировать большие файлы. Если вдуг оказалось бы, что она быстрее всех представленных, как бы ее переписывалт буква в букву?
Насчет std::sort тоже не уверен в данных условиях (кстати, почему qsort тем более? Это же одно и то же практически). Но во времена, когда 640K хватало каждому, забавлялся с сортировкой. Лучшие результаты получались как раз с quicksort. Тогда приходилось сложную схему пейджинга городить, а сейчас можно просто замапить файл.