80 строк на Haskell уделывают в скорости работы сишную портянку

Шо, опять?!

Что?

Когда на Хаскеле напишут хотя-бы ядро ОС, тогда и поговорим. Сишку и Жаба в некоторых алгоритмах уделывает.

Щас начнётся. Что и на Erlang/Elexir легче написать крутой сетевой софт, чем на сишке. Сишку ща пинать модно, но опасно, ибо есть царь. Ща он фекалии подкопит и включит вентиль.

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

Copyright (c) 1980, 1987, 1991, 1993
* The Regents of the University of California. All rights reserved.

Yes, there are faster wc implementations out there.

Исходный код этого древнего wc однопоточный.

Однопоточная версия на хаскеле:

         wc          inlined-monoid-bs-wc
time 	 2.06s       2.73s
max mem. 1.85 MB     3.97 MB

Многопоточные версии на хаскеле против древнего wc(хз почему тут другие значения у wc):

             wc 	multicore-wc 	streaming-wc
time 	     2.07s      1.23s           1.07s
max mem.     1.87 MB 	7.06 MB 	17.81 MB

Лол кек, давай сравним скорость хаскеля и Си, код на хаскеле напишем, а на на си не будим йееееее! Куда они засунули сравниваемый сишный код? Там хаскел один и всё

Для Ъ, за счёт чего?

Явно не из-за священно благословенного духа хаскеля. Почти уверен, код на хаскелле делает что-то не то, что делает код на С. Угадал?

Ты бы хоть гуглил, прежде чем писать:

http://programatica.cs.pdx.edu/House/

там ссылка есть на сишный код: https://opensource.apple.com/source/text_cmds/text_cmds-68/wc/wc.c.auto.html

Я не отрицаю, да вот только импрувинг сишного кода - это задача куда более сложная, чем улучшение кода на Haskell. Да и тут ключевое - _80 строк_. 80 строк, что по скорости близки к уродливой, раздутой и небезопасной сишной портянке.

Ок, теперь взять и переписать чтобы было быстрее thread/ :D

ну так прав значит царь

Я не понял, почему в сорца куча кода, но не как не 80 строк?

Это разные варианты, читай сам пост

Щас начнётся. Что и на Erlang/Elexir легче написать крутой сетевой софт, чем на сишке. Сишку ща пинать модно, но опасно, ибо есть царь. Ща он фекалии подкопит и включит вентиль.

Опасно думать, что царишка копит фекалии. У него константная струя.

В чём конкретно? Он шизофазический бред несёт, я не думаю что там вообще какой-то смысл можно найти, тем более правду.

камингаут защитан )

Там не написано почему он быстрее.

Божественный хацкель предсказуемо обоссал красноглазую сишку. Не вижу никакого повода постить такую обыденщину в Девелопмэнт.

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

Особенно доставило про «мы разогрели и добавили еще 33%». Разогреватели атмосферы, Греты Туттенберг на них нет )

Испанский стыд и голубям на смех, не более ;)

Мамкин борщ.

ибо помогают развенчивать

Где? Хаскель там соснул)

по причине Царь (-7)

Айлолд.

угу, и на потребление памяти посмотри

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

Не поможет. Кто умеет программировать, тому ясно, что утверждение в названии темы - чушь.

Для современности это совсем немного, а писать под что-то с ограниченной памятью я и не предлагаю даже.

калькулятором по голове! 8кб хватит всем.

По времени он начал выигрывать только в момент использования многопоточности (multicore). Но тут скорее удокументированние факта считается, кому нужны подробности. Мои поздравления хаскелистам.

Собрал у себя данную программу для прикола и оно действительно оказалось быстрее на 0.03 секунды, но при этом она не дружит с стандартным входом и принимает только один файл на вход.
(Тестировал на вложенном файле data/big.txt)

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

Одно точно, у этого треда есть потенциал

мусье явно идиот. Референсный код написан очень чисто и красиво, да к тому же максимально портабельно. Ясен пень, что можно сделать кучу всякого и с ним. Как минимум:

1. Выкинуть буферизацию в приложении, использовав mmap

2. Порезать исходный буфер на куски, найти ближайшие границы слов и запустить на каждом куске по потоку, результаты на суммировать

Потому, что не быстрее.

Мне очень нравится haskell, и есть задачи, где он раскрывает свою мощь, но вот в этом конкретном случае мне больше нравится сишный код wc.

И да, не ждите! Царь сюда не придет. Ему доступ закрыли добрые люди. Там ограничение на score.

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

Правильно ли я понял, что код написанный на C в 80-х и изменения в который последний раз вносили более 25 лет назад все равно быстрее хваленного хаскеля со всеми улучшениями? И только добавления многопоточности которого в C-шном коде нету удалось чуть обогнать?
Если это так то хаскель в моих глазах упал еще ниже.

В удалённых посмотри, лол.

Слабоват вброс. Автор специально написал, что НЕ пытается доказать, что один ЯП в чем-то хуже другого. Но ты уже заявил о каком-то развенчании культа...

Удаленные открой, там его величество во всей красе.

Только деградация спасет этот мир, десять строчек на сишке, кнопка на дельфи, клипы малого разрешения и смешные картинки.

А спорим, я на сишке могу написать ещё более тормозное говно?

Ждём адептов жабы в тредике. Уж они точно обгонят всех.

А хаскель умеет векторизацию?

Царский вариант на 20 строк тут: https://tsar1997.blogspot.com/2019/10/blog-post_18.html

We’re actually going FASTER than some C code that’s been hand optimized for a few decades.

Какой идиотизм. Код wc на Си тупой как валенок. Там только read в буфер и простейший скан на \n и пробелы. Никаких оптимизаций, распараллеливания и прочей фигни. Вывод: чтобы обогнать тупой код на Си, на Хаскеле надо изрядно попотеть и поизвращаться.

Царь - красавчик, опять всех зачморил.

Насчет распараллеливания… Что-то мне подсказывает что IO чтения файла по идее должно быть медленнее работы процессора. Процессор просто обязан проверять пробелы быстрее. Если код распараллелить, то прийдется читать из разных сегментов файла, что на жестких дисках может быть не очень. Потому нужно просто читать последовательно. Другое дело что обычные read() будут чередоваться с работой процессора. Чтобы этого избежать лучше использовать memory mapping c head ahead. Это не портабельно конечно, но что же

Царь выше избегает необходимости это делать, возлагая ответственность на bash. Я точно не знаю, но логично что перенаправление вывода файла должно делать readahead и чтение в одну сторону.

Если делать это в утилите, то обязательно пользоваться разной linux-only фигней.

Хаскелль не читал, но что-то мне подсказывать что multicore работает лучше одно потока, потому что код сильно неэффективный чтобы упираться в IO. Автор пишет

One may not expect parallelizing to multiple cores to do a whole lot since presumably this whole operation is IO bounded, but I’m going to do it anyways because I’m stubborn and bored.

но что-то мне подсказывать

У тебя Царский синдром начинает развиваться.