но наверняка ведь на практике всё окажется поддельным

ну и пусть, коль скоро оно позволит забыть про сишечку и баги а-ля https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=c369d66e5426a30e4725b100d5cd28e372754f90

окамл старый

ну мы тут и так забыли это всё

у нас тут другие прблемы - то ленивость, то ленивость

я не вижу причин почему он позволит забыть сишечку industry wide

то gc

окамл в убунте старый

А что за пост, все тот же гист?

да

там в коменты можно и код, и замечания/предложения

https://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell интересный пост , старый правда. в комментах каждый там свой язык разгонял, познавательно

тут в чате уже через час флуда бесполезно что-то искать

Я бы предложил на хабру написать по мотивам, но, боюсь, это вызовет новый поток версий.

dmz@zen ~/tmp/bsfuck $ /home/dmz/.nix-profile/bin/ocamlopt -version 4.03.0 dmz@zen ~/tmp/bsfuck $ /home/dmz/.nix-profile/bin/ocamlopt -unsafe -o zinid ./zinid.ml File "./zinid.ml", line 9, characters 12-32: Error: Unbound value String.split_on_char

с окамлом тут я сдаюсь

если даже в никсе старье, то ой

https://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell интересный пост , старый правда. в комментах каждый там свой язык разгонял, познавательно

С хаскелом тоже не сразу получили оптимальный результат

это про здесь или про там?

там

про там как всегда самая тупая версия на хаскеле наверное выжрала всю память и упала

точнее, НЕ упала что хуже

потому что упала нода, где оно работало.

но тоже не сразу.

про здесь у меня второй вариант работал достат. хорошо.

про там как всегда самая тупая версия на хаскеле наверное выжрала всю память и упала

а OOM killer не успел?

Надо попробовать на гигабайтах входных данных прогнать, тогда можно будет сравнить с жвм языками

мне надо его как-то включить, что ли

он выключен по умолчанию на десктопе

@saksmt на гигабайтах и сишка сейчас загрустит

с реаллоками

Так да

там нужна версия со списками

условия такие, что входные данные надо полностью всосать куда-то внутрь

у меня она вроде уже есть, но как я говорил - ДАНУНАХЕР. хватит уже

задача слишком тупая, что бы так упарываться, в самом деле, сколько можно то

В том и суть - исходная задача же вроде как для большого числа входных данных позиционировалась

реаллоки в си версии вроде нужны только на этапе всасывания и раздербанивания, непосредственно генерация результата работает уже без использования дополнительной памяти

для большого числа выходных

задача слишком тупая, что бы так упарываться, в самом деле, сколько можно то

Тоже верно

для бесконечного потока входных данных - рано или поздно сдохнет всё

потому что хранить надо всё

т.е получается, что в данной задаче - все языки покажут сильно разные результаты в зависимости от размера входа

Мне кажется вы уже проделали офигенную работу, сишка победила -- справедливость восстановлена.

для большого числа выходных

И входных вроде тоже, там тс писал про миллионы строк

на хаскеле просто это особенно ярко всегда проявляется

и быстро

для бесконечного списка данных мы только с первым словом данные выводить можно

и одно дело оптимизировать, что бы быстро работало на небольших входных данных

а другое дело - что бы на БОЛЬШИХ

ну если уж совсем припрет, можно скидывать на диск и поднимать по частям. Но это будет сразу капец скорости. Зато плюс пинок в сторону распараллелливния

потому, что когда будут действительно БОЛЬШИЕ, тут надо будет писать БД

ну или мап-редьюс

там ещё просили не особо жрать проц

кстати, тут можно уже будет поржать, потому что сделать map-reduce из говна и палок на транзиенте - будет быстро

т.е. распараллеливание это минус

ну когда данных МНОГО

и хранить надо ВСЕ

миллион строк входных данных это чот очень много выходных

а входной поток почти бесконечен

то тут только сначала сохранить на кластере

причем ноды и S3 на лету заказывать на амазоне

а потом выводить паросочетания )

=)

Кстати, сейчас все программы по факту однопоточные?

@greenest_pig да

Распределённая числодробилка это пожалуй весело

тут нечего параллелить

да

ну есть чего поидее

задача слишком тупая, что бы так упарываться, в самом деле, сколько можно то

вчера закидывали просьбу о помощи с разбором хаскель кода в идрисе (подозрение на утечку) это может быть уже не так тупо, да еще и полезно

@qnikst тормозит вывод

как ты будешь параллельно заполнять буфер?

ну или каждый поток заполняет свой, а потом они последовательно выводятся? ну фиг знает

N буфферов и writev

учитывая, что размер буфера не сильно влияет вообще на скорость

ну, да.

но это я пас

правда черт знает как себя writev будет вести

тут можно параллелить - каждый процесс берет себе часть префиксов и знает с каким оффсетом его результаты должны лечь в выходной поток. Кидается в файл все например. А потом остается из файла переправить в stdout

если получится сделатьт акую версию на х-ле - которая будет профит приносить - я бы посмотрел