![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Хаскель и среднее арифметическое
Вот я хаскель использовал только пару раз и практически его не знаю, но в чем проблема с неэнергичным foldl - помню. Про то, что нужны банг-паттерны внутри тупла - краем уха слышал, но не вникал.
Стеб же на эту тему людей, которые слышали звон, да не знают, где он, меня очень сильно огорчает.
Ладно, айсед критикует - он хотя бы писал на этом и понимает, о чем речь идет. А так - это выглядит как "разработчики на клиппере критикуют SQL за то, что теория множеств".
Стеб же на эту тему людей, которые слышали звон, да не знают, где он, меня очень сильно огорчает.
Ладно, айсед критикует - он хотя бы писал на этом и понимает, о чем речь идет. А так - это выглядит как "разработчики на клиппере критикуют SQL за то, что теория множеств".
no subject
no subject
no subject
no subject
Для меня это перекрывает бойлерплейт, и при всей моей любви к хаскелю в серьезном проекте я его использовать не хотел бы именно из-за того, что если что-то пойдет не так, то будет кирдык, особенно если программа напичкана какими-нибудь абстракциями высшего порядка. Профайлер скажет что-нибудь вроде "так у вас списки текут!" и приехали.
Когда сделают приличный профайлер или расширение системы типов, решающее такие проблемы, пересмотрю.
no subject
no subject
В отчёте профиля ghc RTS я нахожу проблемное место прямым глазением в подобие дерева в текстовом виде. Часто даже этого не надо, пяток самых тяжёлых функций наверху мне услужливо привели. В отчёте VS 2012 я, если специально не указал нужный модуль в качестве единственного, вообще ничего найти не могу. А если указал, то мне надо сделать десять раскрытий дерева и всё равно можно промахнуться. Например, две функции занимают, примерно, по 20%, но в одной десять вызово по 2%, а в другой, чуть ниже, есть горячий вызов в 18%. И вот ты сидишь, и пялишься на этот тупой список в 10 вызовов.
(не говоря уж о том, что оптимизиррованный код оставляет new промежуточных данных!!!)
В VS я вообще почти на ощупь работаю. Удивительно ущербная система, от тестирования (smallcheck? хаха!) до отладки (eventlog? хаха!).
no subject
no subject
Я помню, что https://github.com/jkff/timeplot/commit/5eba586188e0767c1cf59bc43c45d71ea7e73752 или какой-то похожий коммит у меня занял несколько дней, т.к. профайлер показывал мне какую-то бесполезную бурду (я уже не помню - может, стеки cost centres тогда не умел показывать?), и мне пришлось написать https://hackage.haskell.org/package/htrace, чтобы найти утечку. Возможно, с тех пор ситуация улучшилась - надо будет попробовать откатиться до того коммита и посмотреть, что мне покажет сегодняшний профайлер памяти.
В идеале, я бы хотел видеть профайл количества живых санков и занимаемых ими байтов, разбитый по стекам cost centres, так же как для профайлинга производительности. Такое уже есть?
(Профайлером VS я не пользовался, но в YourKit у меня, кажется, описываемых проблем не было.)
no subject
Я тут недавно баловался профилированием, проблем с поиском проблемных мест не было. Были трудности, как исправить.
Мой анекдот против вашего анекдота.
Насчёт "такое уже есть" это вам лучше самому проверить. Мне хватает отчёта +RTS -p. Дерево вызовов там точно есть, с суммарной и отдельными стоимостями.
no subject