Когда сбор мусора может быть быстрее, чем ручное управление памятью?

При каких обстоятельствах сбор мусора эффективнее ручного управления памятью? (Здесь руководство может означать использование malloc и бесплатно, как в C, или чистые методы RAII и интеллектуального указателя, популяризированные С++)

Мне нравится, как сборка мусора может устранить некоторую случайную сложность при написании программного обеспечения, но я был еще более доволен тем, как RAII и интеллектуальные указатели могут устранить эту сложность, а также работать с ресурсами, отличными от памяти, будучи детерминированными и обеспечивая гарантии производительности и будучи более эффективными в целом. Поэтому я подумал, что могу смело игнорировать сбор мусора. Тем не менее, я заметил, что люди говорят, что сбор мусора быстрее, чем жесткое управление ресурсами, используемое на С++, например, когда доступно много дополнительной памяти.

Итак, когда именно сбор мусора превосходит ручное управление памятью? Мне нравятся RAII и интеллектуальные указатели, но с удовольствием принимаю сборку мусора в качестве другого инструмента, если это быстрее.

Ответ 1

Никогда, и я могу это доказать.

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

Во-вторых, предположим, что лучший алгоритм GC использует времена T0...Tn, чтобы решить, должно ли освобождение памяти i быть освобождено в определенный момент. Тогда общее число Σ(Ti)

Теперь существует эквивалентный алгоритм управления ручным управлением памятью, который использует один и тот же алгоритм GC, но учитывает только блоки памяти, которые были отмечены вручную для освобождения. Поэтому время работы Σ(δiTi) (при δi = 0, когда блок я не был освобожден, и = 1, когда он был).

Очевидно, Σ(δiTi) ≤ Σ(Ti): есть ручной алгоритм, который строго не хуже алгоритма GC.

Как это контрастирует с другими ответами?

"С RAII вам нужно освобождать каждый раз, когда вы выделяете". - Нет, это ошибочное предположение. Мы должны сравнивать либо сгруппированные, либо без пакета операции. GC будет намного хуже, если вы также выполняете GC-сессию каждый раз, когда что-то выходит из сферы действия.
"Улучшенная локальность" - ну, если вы не снижаете тот факт, что языки, отличные от GC, могут использовать стек гораздо чаще, и этот стек имеет отличную локальность ссылок.
"низкие коэффициенты утечек" - это полностью верно, но мы обсуждали производительность во время выполнения. (Кстати: хорошо указать, что это низкие, но отличные от нуля).

Ответ 2

Преимущества GC:

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

Недостатки GC:

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

Это безумие для перфоманса, GC без проблем обойдется в распределитель кучи. Конкурс китайских программистов по программированию между Рико Мариани и Раймондом Ченом часто цитируется, обзор здесь. Программа Raymond С++ в конечном итоге выиграла, но только после ее перезаписи несколько раз и отказалась от стандартной библиотеки С++.

Ответ 3

Существует один конкретный сценарий, в котором указатель GC намного быстрее, чем интеллектуальный указатель (указатель на подсчет ссылок), когда оба реализованы в традиционном С++ (т.е. не С++/CLR, поскольку у нас не будет такой же роскоши, как Compact память после Mark-Sweep, и мы пытаемся сравнить яблоки с яблоками здесь, насколько мы можем), предполагая, что GC использует один и тот же основной менеджер памяти кучи. Это когда время назначения объекта значительно перегружает время создания объекта.

Примеры включают сортировку, разворот массива и т.д.

См. здесь больше информации о моем тесте с каркасом GC, который я реализовал с использованием традиционных ссылок С++ и ссылок на ссылки. Результатом теста разворота массива был GcString, который был в 16,5 раз быстрее, чем ref counted.

Это можно отнести к мучительно медленной семантике блокировки шины в указателе с подсчетом ссылок (если вы не нацеливаете только однопоточные приложения, для обеспечения безопасности потоков необходимы блокировки). По моему опыту внедрения высокопроизводительного точного GC в традиционном С++, я могу сказать, что есть больше возможностей для оптимизации с помощью руководства GC vs 'manual' (в соответствии с определением ОП ручного управления) (т.е. Интеллектуальными указателями).