первое нужно помнить, что в языке с gc аллокации гораздо дешевле, чем в иммутабельном, так же как и деалокация короткоживущих объектов

(не считая аллокации на стеке и прочую радость)

поэтому какой-нить аккуратный фьюзящийся алгоритм на векторах может всего-лишь в 1.1-1.3 раза проигрывать сишному коду (если там автор не навтыкает sse руками)

но наверное это уже оффтоп по сравнению с тем, что тут обсуждали

есть еще подобное чтиво? https://blog.jakuba.net/2014/07/20/mutable-state-in-haskell.html

@Vladimir_Sentsov в иммутабельном языке есть gc

и поэтому там аллокации дешевые

дороже, чем на стеке, но на стеке юзкейс ограничен

черт, на henrychern.wordpress.com убрали содержание

а, нет, ложная тревога

кстати, мутабельность особенно в конкурентном окружении может быть сильно переоценена

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

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

локальность штука интересная

у haskell компактирующий gc

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

который сишная либа с openmp и радостями и считается одним из лучших решений

так вот, начиная с какого-то размера графа haskell начинал обгонять сишный код, причем в разы

т.к. у haskell куча собиралась и сжималась, и не было проблем с аллокациями, т.к. частый malloc/free приводил к тому, что у сишки работа с памятью дороже

несмотря даже на специальные представления графов запросов и т.п.

у нас тупо поверх IntMap было сделано

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

я не застал когда этот код писался, но я тестил это и результаты подтверились

кстати либа есть на hackage

не то, чтобы доделана и исходники только те что на hackage без истории

кстати либа есть на hackage

это ты про какую?

круто. граф (связи) обычно представляется в виде 2мерного массива, откуда там частые аллокации, компакты?

GraphHammer

@vlastachu ну вот у тебя есть граф гигов на 500, представляй

http://stingergraph.com/

можешь почитать у этих ребят и про представления и про алгоритмы

ну тут уже наверное тонкая работа над подгрузкой графа в оперативу

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

ну, ладно. (разбираться в либах/алгоритмах, чтобы поддержать разговор я конечно не буду) из интересных моментов у компактящего гц может быть следующее: есть например многосвязная структура, пускай даже без циклов. и у гц стоит вопрос какие звенья ближе компактить - ведёт ли он для этого статистику чтений?

не ведёт

более чем уверен

с другой стороны он же перемещает сначала что видит

т.е. или depth или breadth first будет рядом складывать

статистика это ж дорого

вообще я так понимаю в gc стараются делать чем меньше тем лучше

ну да наверное

вроде потому и thread local heap (точнее как называлась эта ветка) позволяющая минорные gc делать не stop the world не прижилась

что код очень усложнился в impact почти не было

т.е. или depth или breadth first будет рядом складывать

наверное breadth

скорее всего

можно исходники посмотреть, но лень

было вчера

[begin..end] строится с помошью succ?

Prelude> :t [1.. 2] [1.. 2] :: (Num t, Enum t) => [t] да

Prelude> :t \a -> [a..a] \a -> [a..a] :: Enum t => t -> [t]

Так нагляднее (нет Num)

Только вот там не succ, а enumFromTo

Это отдельный метод класса

Недавно начал изучать Haskell. Я так понял, джентельменский набор — это GHCi и текстовый редактор? IDE никто не использует?

Их нет

Плагины для Sublime/Atom etc

есть среда для MacOS

Haskell for Mac вроде

Скорее всего еще в JetBrain'овских IDE есть плагины

Да, точно http://haskellformac.com

Плагины для Sublime/Atom etc

последнее обновление плагина для idea очень даже ок

А как он сам по себе? Я для Rust плагин юзал и он адски тормозной

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

А как он сам по себе? Я для Rust плагин юзал и он адски тормозной

хз, запилили вроде там некоторые фичи в фоне, всякие хаддоки и прочее

Нужно будет попробовать, хотя для sublime очень даже норм

да ну нах

к саблайм

так жрет проц что ну его нафиг

разница let <> in <> и просто let <> в том что в первом случае let виден только в скоупе in, а во втором в текущем скоупе?

Второе это сахарок для первого :|

так жрет проц что ну его нафиг

Ну тут уже приходится выбирать. Либо проц, либо оператива

Второе это сахарок для первого :|

почему?

Ну тут уже приходится выбирать. Либо проц, либо оператива

нет проблем ни с idea, atom, hfm

Ну а где ты видел let без in кроме как в do?

idea написана на джаве, она по определению жрет оперативу как скотина

Ну а где ты видел let без in кроме как в do?

Prelude> let a = 1 Prelude> a 1

Ты не поверишь

Внутре ghci жирное do в IO монадке

это да)) все в IO живет

🤔