Какие-либо достоверные данные о GC против явной производительности управления памятью?

Question

Недавно я прочитал отличную статью Дэна Гроссмана "1001 * Транзакционная память / аналог сборки мусора ". Одно предложение действительно привлекло мое внимание:

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

До этого мое чувство всегда было очень расплывчатым. Снова и снова вы видите заявления о том, что GC может быть более эффективным, поэтому я всегда держал это понятие в затылке. Однако после прочтения этого у меня начались серьезные сомнения.

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

Это все экспериментально для меня. Кто-нибудь, особенно в контексте C ++, выполнил всеобъемлющий тест производительности GC по сравнению с явным управлением памятью?

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

РЕДАКТИРОВАТЬ: И пожалуйста, обратите внимание на проблему производительности , а не на то, почему существует GC или почему это выгодно.

Приветствия

Карл

PS. Если вы уже вытаскиваете огнемет: я не пытаюсь дисквалифицировать GC, я просто пытаюсь получить окончательный ответ на вопрос о производительности.

Answer 1

Примечание: еще один интересный эксперимент, который я не видел, чтобы его попробовали, сравнить с просто утечкой. Звоните выделять и никогда не бесплатно. Это интересная альтернатива.

За исключением долго работающих серверных приложений, вам никогда не будет не хватать памяти на практике, ОС просто начнет использовать диск для виртуальной памяти (машины имеют практически бесконечную память, вплоть до пределов виртуального адресного пространства, что я думаю, что это огромный сейчас с 64-битными машинами). Это подчеркивает, что GC - не что иное как устройство для улучшения местоположения. Протекшие / мертвые объекты не «травмируются», когда у вас бесконечная память, за исключением того, что память имеет иерархическую структуру, и вы хотите, чтобы «живые» объекты находились поблизости и быстро, а «мертвые» объекты находились в далекой / медленной памяти. Если бы каждый объект был размещен на отдельной странице, тогда система виртуальной памяти ОС была бы GC.

Answer 2

Смотри также

http://prog21.dadgum.com/40.html

, где обсуждается «достаточно умный» компилятор. Пейзаж CS / программного обеспечения пронизан идеями / методами, которые могут быть в теории более производительными, чем статус-кво. Но это все змеиное масло.

GC сегодня дорог, и всегда может быть.

Answer 3

Как указывает @dribeas, самое большое «затруднение» эксперимента в статье (Hertz & Berger) заключается в том, что код всегда пишется с некоторыми «неявными предположениями» о том, что дешево и что дорого. Помимо этого, экспериментальная методология (запуск Java-программы в автономном режиме, создание оракула времени жизни объектов, инструмент обратно в «идеальных» вызовах alloc / free) на самом деле довольно блестящая и яркая. (И мое личное мнение таково, что путаница не слишком сильно умаляет их результаты.)

Лично мое внутреннее чувство заключается в том, что использование среды выполнения GC означает принятие в ваше приложение показателя производительности в три раза (GC будет в 3 раза медленнее). Но реальный ландшафт программ полон путаницы, и вы, скорее всего, найдете огромный разброс данных, если сможете провести «идеальный» эксперимент на множестве программ во многих областях приложений, причем GC иногда побеждает, а Manual часто побеждает , (И ландшафт постоянно меняется - изменится ли результат, когда многоядерность (и программное обеспечение, разработанное для многоядерности) станет основной?)

Смотрите также мой ответ на

Существуют ли статистические исследования, указывающие на то, что Python "более продуктивен"?

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

Answer 4

Теоретически, GC может быть быстрее в некоторых случаях, но я никогда не видел этого, и я сомневаюсь, что когда-нибудь смогу. Кроме того, C ++ с GC, такой как Boehm GC, вероятно, всегда будет медленнее, потому что он консервативный. Со всеми указателями в C ++, GC должен делать вид, что все является указателем. С таким языком, как Java, он может точно знать, что является указателем, а что нет, поэтому он может быть быстрее.

Answer 5

Теоретически, хорошо профилированная программа может информировать интеллектуальную подсистему ГХ для достижения описанных ускорений по сравнению с ручным управлением памятью. Эти ускорения могут не отображаться без продолжительного времени выполнения, чтобы амортизировать фиксированную стоимость запуска GC.

На практике вы, скорее всего, НЕ реализуете эти ускорения с современными реализациями GC. Кроме того, вы НЕ получите окончательного ответа, потому что всегда будут патологически плохие сценарии для обоих случаев.

Answer 6

Это тот факт, что разработчики являются людьми и упускают вещи, которые вызвали необходимость сборщиков мусора в первую очередь. С учетом вышесказанного позвольте мне сказать, что сборка мусора всегда будет медленнее, чем совершенное явное управление памятью. А сборка мусора может часто быть быстрее, чем несовершенное явное управление памятью, учитывая тот факт, что сборщики мусора убирают то, что разработчики склонны забывать.