?

Log in

No account? Create an account
Почему в HN нет GC - Дважды мудак — ЖЖ [entries|archive|friends|userinfo]
Декларативное рулит

Site Meter

[ website | Мой сайт ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Почему в HN нет GC [янв. 18, 2011|18:20 pm]
Andy Melnikov
Заглянув случайно в RSDN, нашёл там эпический тред об управлении памятью в С++.

В нём цитаты:

1) garbage collector это некошерно потомучто нельзя определить точный момент вызова деструктора."

2) Q: Есть же gc-решения для С++. Вы их пробовали применять?

A: Пока нет, надо посмотреть, хотя смущает то, что они "неточные" (то есть какой-то объект может недетерминированно не удалиться?!) и потенциально непортируемые

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

В целом идея HN - направить нечеловеческие усилия невежественных сишников в нужное русло без отучивания от стереотипов.
СсылкаОтветить

Comments:
From: sleepy_drago
2011-01-18 08:08 pm
кстати пока не убедили. именно невежественных сишников.

проблемы 1го порядка как решить задачу за nlogn
проблемы 2го порядка как распараллелить на 8-16 цпу
проблемы 3го порядка как втиснуть датасет в память без потери асимптотики для дизайнов "серьезного размера".

если я для новой задачи сижу в начале то зачем мне GC? У меня пригодных к нему данных отсилы 5%. И там прекрасно канает тупорылый контейнерный говнокод. Да - std::string и тысячи его копирований амортизируются миллиардами транзисторов так что и в микроскоп не видно.

на полном серьезе думаю что до решения основных проблем придется писать на том что вы генерируете так как одно и то же.
(Ответить) (Thread)
[User Picture]From: nponeccop
2011-01-19 05:36 pm
Пишите понятнее, пожалуйста. Так мне либо прийдётся гадать, либо переспрашивать. За переспрашивание "очевидных" (но отсутствующих в тексте) моментов меня, как правило, банят, поэтому буду угадывать, что же вы имели ввиду своим туманным текстом.

Я сам сишник, и прекрасно осведомлён о порядках различных проблем. Я ни в коем случае не агитирую ни за GC, ни против GC. Я лишь говорю, что большинство разработчиков используют или не используют GC по неким нетехническим умозрительным причинам. Я не знаю ни одного человека, который бы проводил какие-то измерения для обоснования своих решений. Потому что использование первого попавшегося решения дешевле точно выбранного, т.к. точность выбора небесплатная - надо писать какие-то тесты и пр. "Проще" и дешевле просто как умеешь делать: если ты привык к GC - то и пиши с GC, а если привык без - то и пиши без. Меня смущает только, что признавать подобные стереотипы постыдно, и разработчики языков не оптимизируют языки под эти психологические особенности (стереотипы) разработчиков.

Теперь о проблемах. То, что вы пишете - актуально, только если вы "сидите в начале". Я пишу HNC для переписывания старого проекта, в котором все эти задачи давно решены. Масштабы системы я приводил - система линейно масштабируется на 40 ядер, MPI в топологии звезда, памяти 4 гб на слейвах 16 гб на мастере (память мастера используется практически только для merge sort, память слейва - практически затянутые в память 4 гб конфигов, не меняющихся в процессе работы), датасет 20 гб считается "маленьким", в среднем 50-100, иногда необходима обработка всех исторических данных свежей версией системы, пока было максимум 1.5 тб.

Так вот. Реализации контейнеров и распараллеливалки очень стабильные. Только изредка надо дописать новый какой-нибудь контейнер или доходят руки до чуть более оптимального MPI-шедулинга ворк юнитов.

Основная же масса работы идёт по модификации как раз этого "контейнерного говнокода с std::string" (в моей системе тоже всё так, как и у вас), и это меня заебало.

HNC позволит писать в разы меньше этого говнокода за счёт синтаксиса, вывода типов, полиморфизма, функций высоких порядков и убогости языка. На С++ даже с С++0х получается заметно больше, чем могло бы быть.

А сами эти контейнеры и распараллеливалки можно пока и на С++ писать. Для HNC основная задача - как раз упрощение, сокращение и обезглючивание этого говнокода.
(Ответить) (Parent) (Thread)
From: sleepy_drago
2011-01-19 08:31 pm
мы с вами уже обсуждали нашу специфику у меня.

> Теперь о проблемах. То, что вы пишете - актуально, только если вы "сидите в начале". Я пишу HNC для переписывания старого проекта, в котором все эти задачи давно решены.
это хорошо если проект приносит прибыль во время этого процесса. у нас другая специфика - инвестор и проект на фиксированные деньги. Результат потом продавать и зарабатывать будут другие и то если результат будет. Соответсвенно основной объем сложности - код который обрабатывает гига-данные. Там много, сложно, ГЦ не выживет, и нужно получить выигрыш/результат против С/С++ кода живущего годами.

Соответственно "остальной код" как бы объемен и глючен он не был нам по барабану. издержки мейнтенанса нас волнуют только в коде где все достоинства GC не существуют и краткость приветствуется только если нет замедления.

ps кстати в нашей бизнес-модели вылезли толстые короткие грабли и вероятно скоро я буду искать где бы уменьшать издержки от с++ :) так что можно не волноваться.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: nponeccop
2011-01-20 12:59 pm
Вот вы сами пишете, что они "отвергают саму идею". Это ж означает, что
отвержение идеи носит умозрительный идеологический характер и никакими сверххорошими реализациями и никакими рациональными аргументами их не заставить.

Вот вы можете себе представить набор недостатков, после устранения которых вы однозначно перестанете идею отвергать? Утверждение о невозможности применения GC при написании систем, для которых традиционно используется С++ - нефальсифицируемо и, следовательно, ненаучно.

О скорости, в-общем, известно с 1987 года как минимум - есть статья "Garbage Collection Can Be Faster Than Stack Allocation" в которой рассказывается, что за счёт того, что расходы на деаллокацию могут быть асимптотически нулевыми, расходы на управление памяти могут быть меньше, чем при стековой дисциплине, за счёт того, что оверхед - только 1 "инкремент" на блок, а аналог "декремента" имеет асимптотически нулевой оверхед. Микробенчмарки, в-общем, это подтверждают.

Основная проблема производительности GC, актуальная для сишников - это не скорость, а позднее удаление. Для того, чтобы быть быстрым, GC трассирует и удаляет редко, так что программа потребляет больше, чем могла бы потреблять. Практически, как я понимаю, для хороших генеративных сборщиков это означает, что количество памяти, равное утроенному количеству свежих аллокаций, пропадает зря. Таким образом, GC неприменим для систем с большим количеством свежих аллокаций и требованиями экономии памяти.

Из непроизводительных проблем - это плохо исследованные GC c RAII. Работы известны, но за пределами исследовательских хеллоу ворлдов пока не применяется. Я вообще не представляю, как люди без этого RAII живут. Джависты мне рассказывали, что с файлами работают, как в Си, а финализаторы используются только для отладки: если файл на момент вызова финализатора не закрыт - бросают фатальное исключение, означающее баг. Закрывать же файл в финализаторе - моветон, т.к опять же из-за требований скорости он может жить довольно долгопосле того, как стал unreachable.

Какие ещё проблемы я забыл?

Касательно лагеря GC-шников - они также почему-то закрывают глаза

1) на RAII, отсутствие которого делает возможным утечки других ресурсов помимо памяти, и
2) отсутствие гарантий отсутствия утечек за счёт возможности счёт накопления данных, которые reachable but dead.

И, конечно, их миф что управление памятью серьёзно нагружает программиста, смешон.

Короче, сплошное религиеведение.



(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: nponeccop
2011-01-20 02:03 pm
Так в том и дело, что непонятно, что они имеют ввиду, когда что-то говорят. Слова RAII ведь там не было. Человек, знающий поверхностно, увидит только одну интерпретацию, соответствующую его невежеству. Чем глубже человек понимает обсуждаемую проблему - тем больше возникает интерпретаций, тем бесполезнее использование русского языка в беседе с ним и тем необходимее придерживаться стандартных терминов и чёткости изложения.

То, что никто не спросил в топике уточнений - как раз и говорит что все участники беседы одинаково дилетанты, т.к. каждый нахватался по верхам, видит только одну какую-то интерпретацию, и поэтому не переспрашивает.

С GC можно много проблем разных придумать, связанных с нарушениями порядка. Как понять, что они имели ввиду?

Вот например такая проблема:

Известно, что GC удаляет только недоступные объекты, а ручное удаление - только доступные.

Скажем, если есть связная цепочка объектов A->B->C, то при сборке мусора удалится сначала A, потом B, потом С, а в случае ручного управления удалится сначала С, потом B, потом A. Поэтому писать код, работающий как при ручном удалении, так и при сборке, крайне сложно.

Как понять, имели ли они то, что я написал в прошлом комментарии выше в этом треде, то, что я написал только что или то, что potan написал ниже? Как понять, имели ли они вообще ввиду что-то определённое, или у них были какие-то туманные ощущения, которые они в туманном же виде переложили на бумагу? Как понять, видят ли они смысловую разницу между тремя текстами, или считают, что это одна и та же проблема, записанная разными словами? В последнем случае непонятно вообще как c ними говорить, раз они похожее считают одним и тем же.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: nponeccop
2011-01-20 02:38 pm
Но как понять относительную важность разных проявлений? Бороться же можно только поодиночке. И для борьбы надо чётко сформулировать проблему. Формулировка "все возможные проявления" не позволяет сколь-либо продвинуться в решении.
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2011-01-20 03:07 pm
Ещё важно собрать статистику о соотношении "контейнеров" и "говнокода". Скажем, у геймеров говнокода довольно много, и HNC нацелен на ту нишу, которую сейчас у них занимает LuaJIT.

В говнокоде практически голый RAII без сложных передач объектов от одного владельца к другому, не определяется структур данных (строго говоря, абстрактных типов данных). У меня говнокод отъедает примерно 30% всего времени исполнения, 65% контейнеры и 5% шедулинг, ввод-вывод и пр. Т.е. требования к скорости говнокода высоки, но не так высоки, как у контейнеров, т.е. есть надежда, что предложенная в http://code.google.com/p/inv/wiki/FoldExample (и отработанная многократно, скажем, в http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.6545) схема говнотрансляции ФВП и полиморфизма не только даст идиоматический код на выходе, но и будет сравнимой по производительности с LuaJIT.
(Ответить) (Parent) (Thread)
[User Picture]From: love5an
2011-01-27 11:26 am
RAII для ресурсов, которые надо контролировать, в нормальных языках делается тривиально - with-open-file и подобными макросами/функциями высшего порядка. В плохих языках(ну, в некоторых) есть IDisposable и подобное.

Про аллокацию:

В хороших реализациях хороших языков, вроде SBCL, объекты точно так же можно складывать на стек(по крайней мере, некоторые виды объектов, но и того достаточно), и, естественно, работать через выделенную заранее память.

А вот когда дело доходит до динамической памяти, то тут GC выигрывает однозначно, потому что malloc/new и друзья это тормозное и неэффективное говно, свой аллокатор - не факт что будет лучше них, плюс его еще надо написать, и, естественно, от утечек памяти он не 100% что спасет. А если спасет - это уже tracing GC, т.е. велосипед, причем, с большой долей вероятности, кривой.
Про shared_ptr и прочее подобное говно я не говорю даже, это не сравнится с нормальным GC ни по памяти, ни по производительности.
(Ответить) (Parent) (Thread)
From: (Anonymous)
2011-01-19 05:22 am
особенно испугало слово "отучивание" -- это принудительное наведение мозговой тучи?
(Ответить) (Thread)
[User Picture]From: nponeccop
2011-01-19 04:48 pm
Отучивание - это отвивание старых механических навыков и прививание новых.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: nealar
2011-01-19 11:49 am
"для начача" им бы самим понять, что они имеют в виду
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: nealar
2011-01-19 12:33 pm
Из неправильного использование ГЦшной терминологии.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: nealar
2011-01-19 12:41 pm
"Точный" ГЦ - это не значит, что он объекты прибивает "чотко вовремя".
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
From: nealar
2011-01-19 12:53 pm
Вот именно об этом проф и пишет.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
[User Picture]From: potan
2011-01-19 01:43 pm
Например деструктор снимает лок с файла. То есть пока GC объект не удалет, некий файл останется залочен.
А такие деструкторы плюсовики любят - вместе с автоматическим удалением локалных обхектов в конце блока это позволяет просто делать критические секции.
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: nponeccop
2011-01-19 04:46 pm
Глупость
(Ответить) (Parent) (Thread)
(Удалённый комментарий)
[User Picture]From: nponeccop
2011-01-19 04:57 pm
Меня смутила глупость участников той беседы.
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2011-01-19 05:37 pm
Точнее, не участников (оценить умственные способности по кратким пассажам не представляется возможным), а самой этой беседы. Что она даёт участникам?
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2011-01-19 04:58 pm
> для начача надо понять что они имеют в виду

Меня смутило, что они не пишут, что они имеют ввиду
(Ответить) (Parent) (Thread)