для set bytestring-ов

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

вы вроде бинарный поиск по хранящимся одним куском байтстрингам делали

угу

и там сет иммутабельный был

так чего по итогу? насколько питон обогнали?

раза в два

1.35-1.45 vs 2.22-2.36 в пользу haskell

в полтора на моём ноуте

даже и не в два

но это без ада с FD и т.п.

щас их попробую

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

почему никто ещё не инкапсулировал весь этот ад в либу для быстрого io?

это ж много работы

хаки с IO не дают больше 1-2% тут

сделать их правильно - тяжело

еще и обобщенно

мерять нормально задолбаешься

1-2% это в пределах погрешности

а в чем ботлнек был изначально?

грубо говоря 2шт: 1. list 2. неудачные дефолты для этой задачи в IO

первое решается вектором

второе решается fast-builder-ом с большим чанком

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

питон с jit наверное может себе это позволить

увидеть что там stdout и пойти в fast-path

да я так понял, там просто более разумный дефолтный размер для чанка

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

С дефолтным билдером работает не оч. А с fast-builder попробую завтра.

кстати в коде base описаны прикольные не сделанные оптимизации

с дефолтным даже при большом чанке - 4с

в 2 раза хуже примерно

А как там рулить размером чанка?

через import Data.ByteString.Builder.Extra

toLazyByteStringWith

да, автор фастбилдера не зря старался

вообще я честно говоря поражен

(и реквестировал всякие фичи вроде ваншот аннотаций не только для функций над Type)

я когда его прочел побоялся понять на каких кругах ада он оперирует

комментарии по поводу потоков в документации тоже неизгладимое впечатление оставили, конечно

Всем спасибо, я на сегодня все. Завтра почитаю еще.

а я хотел в 9 лечь спать :(

Какой итог?

Надо использовать фастбилдер?

Питон победили ценой нескольких человекочасов.

И вектор вместо списка

@voidlizard ну. если не страшно использовать пакет с документацией вроде такой > Performance hint: when the resulting ByteString does not fit in one chunk, this function forks a thread. Due to this, the performance degrades sharply if you use this function from a bound thread. Note in particular that the main thread is a bound thread when you use ghc -threaded. To avoid this problem, do one of these: Make sure the resulting ByteString is consumed in an unbound thread. Consider using runInUnboundThread for this. Use other function to run the Builder instead. Functions that don't return a lazy ByteString do not have this issue. Link your program without -threaded.

Какой итог?

Питон победили ценой нескольких человекочасов.

Теперь надо попробовать c++ победить!

Реально это?

нет

А насколько плюсы быстрее, не мерили?

нет

На SO видел несколько раз, как хаскель обгонял чистый си

Но там не IO был конечно

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

а ещё вывод, похоже в байтострокобилдере бага

надо будет завтра копать чтож там такое

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

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

Может это не баг а фича?

на фичу не похоже

слуште. у меня идеоматичная версия на обычном билдере - в два раза быстрее, чем pypy версия

сейчас зачищу от лишнего

просто Builder, просто списки

6 секунд против 13

для pypy

давай, интересно

https://gist.github.com/voidlizard/83c06a758b20697019aa063b16cded94

да я вообще там ничего не делал, только Builder.hPutBuilder использовал

всё остальное вернул к идеоматичному виду

вектора в топку

настройки буферизации убрал

генерируемые файлы идентичны.

нормальный вид с векторами ^_^

дойду до ноута посмотрю, очень интересный результат

вчера использовали hPutBuilder ?

он плох был

у меня