A64m
нинадо никогда Werror использовать
Vasiliy
неопасные варнинги можно отключить
A64m
был бы у ghc именованный набор варнингов где что-то полезное только вроде ПМ проверяется, затенение (хотя это уже сомнительно)
A64m
там половину отключать тогда
A64m
Wall просто исторически был помойкой где все ворнинги
A64m
сейчас уже не так, новые тутда по умолчанию не попадают
Vasiliy
ну либо -Wall и половину отключать, либо без -Wall и другую половину включать
Vasiliy
был ещё тред с полезными варнингами https://www.reddit.com/r/haskell/comments/6q9tcp/ghc_warnings_you_should_use_in_addition_to_wall/
Dmitrii
А чем закончилась та телега (специальная олимпиада) с байтстрингами и соревнованием на скорость? Честно, очень много писали, тяжело за всем следить... Мне кажется, что было бы неплохо написать пост на Reddit о достигнутых результатах и встреченных проблемах, сообществу может быть интересно (ну как минимум мне интересно)
Aragaer
там на си написали вариант, который может всего на 20% медленнее, чем просто забить выходной файл нулями
Dmitrii
Ну так это всем понятно, что Haskell используется не ради супер-скорости и выжимания максимума из машинки...
A64m
Еще не закончилась
Dmitrii
Имею ввиду хороший пример того, как должен быть организован код в либе
Ещё можно присмотреться к этой туле, она позволяет не особо думать о структуре проекта, а сразу получить готовый результат со всякими свистелками
https://github.com/vrom911/hs-init
Alexander
@chshersh на моём компе 0.20 с - haskell лучший - 1с
Alexander
у Димы, где основные замеры меньше разница
A64m
а он самый новый хаскель разве измерял?
Alexander
неа, наверное
Alexander
там патченный fast-builder надо
Alexander
давайте я вечером автору пошлю, там минимум для CStringLen нужно билдер добавить
Alexander
вот из интересного, попытки использовать ветора больше и storable вектор, приводят у **ужасному** падению скорости
A64m
скажем прямо, пропатчить фаст-билдер самому не великий труд, если патч есть, не говоря уже о том, что можно подцепить просто репозиторий с патченным фастбилдером
Alexander
ну я ж ни того, ни другого не подготовил
A64m
сторабл вектор больше тормозит? Это интересно
Alexander
так вот foldr . foldr вообще дико убивает все
Alexander
у меня рекорд был 16с
Alexander
анти-рекорд
A64m
неплохо
Alexander
в коре вообще ужас какой-то
Alexander
дикие листинги на 100500 экранов
Alexander
@A64m_qb0 это не storable это unboxed были
Alexandr
Alexander
storable я не попробовал, мне было лень включать ноут
Alexander
и я сел играть в factorio
Alexander
а можно hs-init которому stack не нужен?
A64m
надо будет мне поэкспериментировать
Alexander
а вспомнил
A64m
был же какой-то hi
Alexander
я хотел foldr из Traversable заюзать
Alexander
надеясь что он может не будет фьюзиться
Alexander
ты ж помнишь у меня в v-stream F.foldMap (.. foldr)
Alexander
это чуть лучше чем F.foldMap ( F.foldMap)
Alexander
и гораздо лучше чем V.foldr (V.foldr )
Alexander
ещё что мне не хватило:
a. Lazy.Vector по аналогии с LBS
б. задание дефолтной capacity при сборке вектора
Alexander
ленивый вектор бы был полезной штукой, index не так и страдает, и нету проблем как со строками если запретить "под-вектора" вытаскивать
A64m
а в vector-bytestring был обобщенный лази вектор или только сторабл под байты?
Alexander
хм.. не знаю
Alexander
смотрю
Alexander
специализированный
A64m
хотя да, обобщенный бы лишнюю ссылку давал на чанк
Alexander
в принципе для данного случая запилить не сложно
Alexander
тем более, что мне только foldable + инициализацию нужно
Alexander
@chshersh максимальный прирост производительности в си (последний прыжок) был на:
if (len > 8) memcpy(dest, src,len)
else memcpy(dest,src,8)
Dmitrii
Мне больше интересно, не как Си сделать быстрей, а чем руководствоваться кроме бенчмарков (какими принципами и какими правилами) чтобы случайно не написать неэффективный код на Haskell, который вроде бы выглядит нормально, но иногда написав немного по-другому можно получить существенный прирост в производительности (или убыль).
Dmitrii
Лучше бы на этом сайте запилить как-нибудь программы на Haskell с адекватной производительностью, а то даже нет источника с хорошими результатами производительности, который можно было бы скидывать людям... http://benchmarksgame.alioth.debian.org/u64q/haskell.html
Alexander
core смотреть и мерять
A64m
ну вот на си был разброс от 0.2 до 12, на хаскеле от 1 до 50, вполне сравнимые разбросы
A64m
языков общего назначения, на которых нельзя "случайно написать неэффективный код" просто не существует
A64m
одно можно сказать точно, если код выглядит нормально - вряд ли он эффективный
Alexander
вообще у нас на практике, если вдруг работает медленнее чем ожидалось бы - смотреть
Alexander
Мне больше интересно, не как Си сделать быстрей, а чем руководствоваться кроме бенчмарков (какими принципами и какими правилами) чтобы случайно не написать неэффективный код на Haskell, который вроде бы выглядит нормально, но иногда написав немного по-другому можно получить существенный прирост в производительности (или убыль).
Вот кстати в книжке Samuli Thomasson'а "Haskell High Performance Programming" есть кое-какие советы,
например, следить, чтобы мемоизация работала
Alexander
Pact ?
Alexander
вообще с fusion и rewriting rule все сложно
Alexander
т.к. например в этой задаче, некоторые решения которые я думал что будут работать лучше - работали хуже
Alexander
а самое противное, что когда пишешь большой проект вообще не обращаешь внимания на эффектвность пока не бомбанет
A64m
да фьюжен это не такая штука, на которую можно полагаться, это когда в ряде случаев какие-то промежуточные результаты не создаются, и в среднем скорость получше становится.
A64m
можно, конечно, сосредоточнится на небольшорм куске кода и всякими непрямыми манипуляциями довести фьюжн до нормального результата, но это не совсем здоровая ситуация
Alexander
бесит что если оно иногда все портит, и неясно что делать
Alexander
вон с 1 секунды до 16 если я поменял foldMap на foldr
A64m
да, это странно на таком числе уровней, что замучаешься перечислять
A64m
начать с того, что в инстансе фолдабла для вектора foldMap вообще не имплементируется, используется дефолтное определение через foldr
Alexander
у меня такое предположение: при foldMap оно меньше инлайнит
Alexander
т.к. он не реализован правильным лдля вектора способом
Алексей
А потом обнаруживаешь 100-кратную просадку производительности потому что что-то не заинлвйнилось
Alexander
имхо если не заинлайнилось, этого хотя бы ожидешь
Alexander
и примерно понятно что делать
Alexander
в крайнем случае обложить все inline :: a -> a
Alexander
что делать в случае наоборот я не знаю
A64m
Вообще не хватает библиотек, которые просто не компилируются, когда с фьюженом не сложилось, а не весело тормозят как ни в чем не бывало. Понятно, что для оптимизации всяких списков это не вариант, но во многих случаях нужно именно это
Alexander
хм.. где-то ж было такое?
Alexander
nomeata писа