тут не списки против векторов

но я удивлен

все равно непонятно, как жить. вот написал ты код, он как-то работает

откуда, в общем случае, тебе узнать, что оно тормознее pypy ?

написать заодно на pypy и устроить бенчмарк?

кстати, как работает pypy ? это что вообще такое?

когда я пишу кож мне пофиг и.к. я убьюсь тоже самое на питоне писать

и мне пофиг на скорость пока это не concern

ну вот эта вся история с байтстрингами - оно критично в серверах

например

как только это становится проблемой, то меняю и меняб

ну на серверах ты не будешь по 110000 байт в сеть дампать

ну тут же непонятно, это наш хаскель тормозит, или в какое-то фундаментальное ограничение уперлись

там мне кажется хаскельный дефолт ближе к реальности

и.е. там понятно за что платишь за IO manager и вроде оно и надо делать

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

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

все стримы обычно медленнее лази ио, как иначе то?

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

машины - тормоза

там нужно 10 авторов fast-builder чтобы их исправить

я не рискнул взять стриминг

и.к. в stdlib не нашел нужного, в планах попробовать streaming-bytestring

но с другой стороны эта задача не очень выстраивается в pipeline

ио из стриминга, кстати, вообще выкинули

stdinLn и stdoutLn есть

ну и у меня он для интерфейсов к lmdb норм пошел

речь про новую версию, ее и не релизили вроде еще

блин

у стриминга новые мейнтейнеры

надо себе таску сделать посмотретл

с другой стороны нормально

ещё бы и string bullshit убрали

а для этой задачи врятли взлетит хорошо, скорее какая-то тупость типа bytesting ,через вектора и append

там, кстати, отличный бенчмарк, иллюстрирующий, как здорово пайпы-кондуиты работаеют copy 200M file divide it on lines, adding '!' to each lazy 0m0.813s 0m8.597s streaming 0m0.783s 0m9.664s pipes 0m0.771s 0m49.176s conduit 0m1.068s 2m25.437s

ну чтобы питонячий join получился

почему там 2 времени?

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

два бенчмарка-то

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

один просто читает и пишет, другой в коне каждой строки ! вставляет

а понял

вставление тормозит байтстринг в 10 раз

явно что-то не в порядке

+ malloc + copy + free + foreign ptr?

но в 10 как-то плохо

да и скорость чтения записи не радует

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

удивлен, что так мало? или так много?

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

что так мало

да и даже самый тормозной поиск разделителя между строками не может так тормозить

а это где такой бенчмарк?

https://github.com/michaelt/streaming-bytestring/blob/master/bench/benchlines.hs

о круто пасиб

а pypy в питоне это мейнстрим?

Ну если код на питоне 2 то если производительность не устраивает просто запускаешь его через pypy и иногда работает в несколько раз быстрее. Jit все-таки.

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

ну т.е влияет, но в пределах погрешности

в общем-то, вполне идеоматично в итоге.

но умнее ничего не придумывается. распараллеливание только всё портит

dmz@zen ~/tmp/bsfuck $ time ./bswtf4 < ./49zGQ6Zt.txt > /dev/null real 0m2.295s user 0m2.160s sys 0m0.136s dmz@zen ~/tmp/bsfuck $ time ./fu2.py < ./49zGQ6Zt.txt > /dev/null real 0m4.613s user 0m4.584s sys 0m0.028s

кейс закрыт?

Не, мне распараллеливание не нужно. Не нужна скорость любой ценой. Нагрузку на cpu к нулю устремить нужно.

кейс закрыт?

Какая финальная версия?

она CPU грузит

но питон его тоже грузит на 100%

Ну все грузит

Это все же фаст билдер?

ну в моём вариате разница между Builder и FastBuilder мала.

можно и так, и так

самая быстрая - последняя версия @qnikst , но в моей последней код попроще

и чуть поменьше

main = do v1 <- fmap (\[a,b] -> (a,b)) . chunksOf 2 . BS.words <$> BS.hGetContents stdin let (p,s) = unzip v1 let wtf = map (\pref -> foldMap (mkb pref) s) p mapM_ (B.hPutBuilder stdout) wtf where mkb s1 s2 = B.byteString s1 <> B.byteString s2 <> B.char7 '\n'

разница мала, думаю, потому, что hPutBuilder у фастбилдера почему-то тормозной и это съедает все его успехи в других местах

@eahqzsr моя вчерашняя версия все ещё самая быстрая

с векторами и fast-builder-ом

но там разница в десятые.

А если в mkb клеить строго байтстринг - медленнее будет?

щас попробую, но да

мою можно ускорить если сделать парсить как у @voidlizard