← All posts tagged gc

lovesan

[ Про управление памятью, ответ на #1762666/9 ]

Полюбому — одни неосиляторы вокруг. В майкрософте неосиляторы на какой-то хуй в COM ввели всю эту поебень с управлением памятью, в GObject там что-то, про извращения из буста и Qt я даже не говорю. А самые самые неосилившие неосиляторы придумали такую хрень как сборщики мусора — пиздец ведь, да? Ну надо же какие неосиляторы то блять, вообще нихуя не осилили — дрочат там какие-то оптимизирующие эвристики автоматического управления памятью, выдумывают алгоритмы для автоматизированного менеджмента ресурсов в многопоточной среде, а какие-то malloc/new/free/delete в нужных местах расставлять — не осилили. Вот лохи то тупые, ебта!



Блядь, когда у тебя программа состоит из чего-то крупнее трех статических массивов с интами и двух динамических с флоатами, которые тебе надо перемножить и вывести на stdout чтобы сдать лабораторку в твоем ПТУ — хуюшки ты уследишь за всем ручками. Это я еще не говорю про коллбеки-интерфейсы, про интеграцию с чужим кодом, про интеграцию с разными языками программирования, с разными рантаймами и прочее. И не надо пиздеть что это все от неосиляторства. "Неосиляторство" это отмазка малолетних долбоебов, даже на тех самых C++ то толком не писавших.

lovesan

вынесу из комментов: juick.com

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

GC как раз очень правильная адаптивная(против halting problem не попрешь) методика, и в 99.99% случаев является лучшим выбором. Но, естественно, правильный, нормальный двигающий GC, которому компилятор помогает всякими там escape analysis.

А GC — если причина тормозов, то по сравнению с чем? С malloc/new? Ну это не смешно даже — последние то это вообще пиздец. Причины тормозов программ на высокоуровневых языках совершенно не в GC.

Причины либо

1) В слишком динамичных рантаймах, а значит в куче метаданных, связанных с объектами, и значит, в постоянном боксинге, промахах кеша и прочем подобном. (примеры — smalltalk, scheme)

2) В кривых компиляторах или рантаймах, написанных криворукими дебилами(python, ruby)

3) В неуемном использовании абстракций, такого уровня, который на языках типа Си и C++ без разрывания жопы пополам просто не достичь. (это основная причина тормозов кода на java и .net)

lovesan

Первый GC для .NET был написан на Лиспе.
И потом переведен в C++ автоматическим source-to-source транслятором.
channel9.msdn.com

Его разработчик, Patrick Dussud, являвшийся главным инженером по части GC в .Net(и являющийся теперь, как MS пишет — lead architect for the .NET Common Language Runtime, the chief architect for the .NET Framework, and is a member of the Window Core Architecture team) — раньше работал в Texas Instruments и других подобных компаниях(например Lucid Inc.) и писал там в частности на ZetaLisp(диалект для Lisp-машин, предшественник Common Lisp) и на собственно самом Common Lisp.
microsoft.com

Так то!

lovesan

Вот собрал несколько умных книжек на тему алгоритмов сборки мусора(garbage collection).

Paul R. Wilson, "Uniprocessor Garbage Collection Techniques"
rghost.ru

Richard Jones, "Garbage Collection Algorithms For Automatic Dynamic Memory Management" (мегакнижка, но качество скана немного хромает)
rghost.ru

Ну и вот, не совсем конкретно по теме, но там есть в т.ч. и про рантаймы языков с GC.
Ахо, Лам, Сети, Ульман, "Компиляторы: принципы, технологии и инструментарий" (рус., 2е издание, 2008)
rghost.ru

lovesan

Сравнил производительность сборщика мусора из SBCL и boost::shared_ptr

Подробное описание теста, с полным кодом программ, дизассемблами и "нотариально заверенными скриншотами":
love5an.livejournal.com

Результаты для "умных указателей" вышли печальные — они тормозят. Причем тормозят просто пиздец.