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

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

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

См. Также

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

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

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

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

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

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

См. Также мой ответ на

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

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

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

GC всегда будет медленнее, чем крайняя альтернатива: совершенное недетерминированное управление памятью.

Вопросы :

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

Существуют и другие области, в которых управляемые подсистемы победили неуправляемые:

В общем, программа всегда будет работать медленнее в многозадачной операционной системе, чем в однозадачной - или на компьютере без ОС.

В общем, программа всегда будет работать медленнее в системе с виртуальной памяти, чем на одного без.

За исключением экстремальных обстоятельств, серьезно ли мы рассматриваем компьютерные системы без ВМ и без ОС?

Berger's paper is being cited a lot, but it is comparing real garbage collectors against a purely theoretical, offline, optimal algorithm. So while it may tell you something about theoretical limits, it says very little about the performance of real garbage collectors versus real implementations of malloc and free. A study that I like better took real programs and compared explicit malloc and free with Hans Boehm's conservative garbage collector:

The Measured Cost of Conservative Garbage Collection by Ben Zorn

This study isn't perfect, and Zorn is careful to note that if the programs knew they were using a garbage collector, some could be made faster. But the hard data is this: - In real programs originally written to use malloc and free, garbage-collected versions run at about the same speed but require twice as much memory. Zorn argues fairly convincingly that if you know you have GC, you can make things faster, but it's hard to eliminate the memory penalty.

I learned more from this careful experimental study than from Berger's study of an unimplementable, idealized memory manager.

Здесь приводится довольно много разных аргументов. Я хочу начать с того, что поясню, что вы не можете проводить сравнение 1: 1. У каждого есть свои плюсы и минусы, и любой фрагмент кода будет более подходящим для той или иной системы.Напротив, это означает, что вы должны знать, есть ли у вас сборщик мусора или нет, чтобы писать эффективный код.

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

Пример:

Программа выделяет тысячи кучной памяти для короткоживущих объектов. То есть он выделяет и освобождает много раз с разными размерами объектов.

В среде, отличной от GC, для каждого выделения вы в конечном итоге вызываете malloc, а для этого требуется найти в списке свободных фрагментов памяти наиболее подходящий (в соответствии с конкретной реализацией malloc). Используется память, а затем она освобождается с помощью команды free [или new / delete в C ++ ...]. Стоимость управления памятью - это стоимость обнаружения фрагментов.

В среде GC с подвижным GC, таким как java или .net, после каждого запуска GC вся свободная память является непрерывной. Стоимость приобретения памяти для объекта дешевая, действительно дешевая (<10 инструкций процессора в Java VM). При каждом запуске GC только живые объекты располагаются и перемещаются в начало соответствующей области памяти (обычно это область, отличная от исходной). Стоимость управления памятью - это в первую очередь стоимость перемещения всех доступных (живых) объектов. Предполагается, что большинство объектов недолговечны, поэтому в конечном итоге стоимость может быть меньше, чем у системы без сборки мусора. Один миллион объектов, выделенных и освобожденных (забытых) за один запуск сборщика мусора, не требует дополнительных затрат.

Заключение: В языках GC вы можете создавать все локальные объекты в куче. Они дешевы. С другой стороны, в системах без сборщика мусора связка выделения, освобождения памяти и нового выделения стоит дорого. Память фрагментирована, и стоимость malloc увеличивается ... В системах без сборщика мусора вы должны использовать стек как можно чаще, используя кучу по необходимости.

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

Ярким примером является неуправляемый программист, который используется для выделения объекта, а повторное использование (сброс его внутренних указателей с новыми элементами по мере необходимости) используется с таким образом мышления: выделение - дорого, повторное использование - дешево. Теперь, если один и тот же точный код будет перемещен в среду GC поколений (Java, .net - обе являются GC move-generational), вы получите забавный эффект. В сборке мусора поколений Java система будет выполнять второстепенные коллекции только для младших поколений, обрабатывая только старшие поколения в полных коллекциях. Но объект в молодом поколении может упоминаться объектами в старшем поколении, поэтому необходимо выполнить дополнительную работу, чтобы отслеживать эти ссылки от старых к молодым. В частности, в Java 1.4.1 сборщик мусора система отметит карту памяти (часть страницы), где находится старый объект, и затем включит все отмеченные карты для обработки во время второстепенной сборки, эффективно увеличивая объем работы, которую должен выполнять сборщик мусора, и, возможно, влияющей на производительность.

Объект был жив во время 1, 2, 3 ... запусков GC, и он перемещался много раз, наконец, перемещен в старое поколение, где он не будет перемещаться при каждом запуске GC, а может просто стоять там ...но увы, программист заставляет объект помолодеть. Он перемещается еще раз, и он будет снова перемещаться каждый раз, когда сборщик мусора подойдет к тому моменту, когда он снова станет старым.

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

Вот эксперимент, который мне нравится проводить:

1. Запустить программу, написанную в среде сборки мусора (например, .NET или Java).
2. Запустите аналогичную программу, написанную в среде без сбора мусора (например, C или C ++).
3. Используйте программы и посмотрите, какая из них более отзывчива.

Улучшение объективности: попросите бабушку выполнить шаг 3.

Хорошо и хорошо процитировать теоретическую производительность оптимальных реализаций GC, но факт заключается в том, что в реальных сценариях программы, написанные на языках с мусором, не выполнять так же, как родные приложения. Вот почему крупные проекты, в которых производительность напрямую связана с пользовательским опытом, все еще программируются на C ++. Классическим примером этого является игровое программирование.

Другой, возможно, нелогичный, Примером этого является Eclipse IDE. Хотя он может быть написан на Java , вся графическая подсистема должна была быть переписана для получения приемлемой производительности. Решение: сделать элементы графического интерфейса облегченными оболочками вокруг собственных (C / C ++) компонентов ( SWT ).

Я понимаю, как работает сборщик мусора. Управление памятью трудно понять правильно. И много работы. Суть заключается в следующем: знание того, как ваша программа должна вести себя, дает вам (программисту) преимущество над машиной , пытающейся угадать .

Я понимаю, что такое сборка мусора. Управление памятью трудно понять правильно. И много работы. Суть заключается в следующем: знание того, как ваша программа должна вести себя, дает вам (программисту) преимущество над машиной , пытающейся угадать .

Я понимаю, что такое сборка мусора. Управление памятью трудно понять правильно. И много работы. Суть заключается в следующем: знание того, как ваша программа должна вести себя, дает вам (программисту) преимущество над машиной , пытающейся угадать .

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

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

Стоимость выделения памяти, как правило, намного ниже в модели памяти с сборкой мусора, чем при явном использовании new или malloc, поскольку сборщики мусора обычно предварительно выделяют эту память. Однако явные модели памяти также могут делать это (используя пулы памяти или области памяти); при этом стоимость выделения памяти эквивалентна добавлению указателя.

Как отметили Раймонд Чен и Рико Мариани , управляемые языки в большинстве случаев не выполняют неуправляемые языки. Однако после его нажатия неуправляемый язык может и в конечном итоге превзойдет язык GC / Joted.

То же самое видно и в Shootout Computer Language Shootout , потому что, хотя C ++ имеет тенденцию занимать более высокое место, чем Java большую часть времени вы Я часто буду видеть реализации C ++, проходящие через различные циклы (например, пулы объектов) для достижения оптимальной производительности. Тем не менее, языки сборки мусора, как правило, имеют более простые для понимания и более простые реализации, поскольку GC лучше распределяет (небольшие куски) память.

Однако производительность не является самой большой разницей, когда речь идет о GC по сравнению с другими. -gc; возможно, именно детерминистическая финализация (или RIIA) не-GC (и подсчитанных ссылок) является главным аргументом для явного управления памятью, потому что это обычно используется для целей, отличных от управления памятью (таких как снятие блокировок, закрытие дескрипторов файла или окна) и так далее). «Недавно», однако C # представил конструкцию using / IDisposable, чтобы сделать именно это.

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

С другой стороны, язык с сборкой мусора может сделать больше всего. оптимальная вещь в самое оптимальное время (или приблизительно) без необходимости обременять разработчика этой задачей. Это означает, что разработка для языка GC может быть более естественной, поэтому вы можете сосредоточиться на реальной проблеме .

язык сборки мусора может выполнять самые оптимальные действия в самое оптимальное время (или приблизительно), не обременяя разработчика этой задачей. Это означает, что разработка для языка GC может быть более естественной, поэтому вы можете сосредоточиться на реальной проблеме .

язык сборки мусора может выполнять самые оптимальные действия в самое оптимальное время (или приблизительно), не обременяя разработчика этой задачей. Это означает, что разработка для языка GC может быть более естественной, поэтому вы можете сосредоточиться на реальной проблеме .

Одна практическая проблема заключается в том, что с явным MM обычно намного проще профилировать, идентифицировать узкое место и устранять его.

С системой GC, когда оказывается, что ваш хороший код O (N) уничтожает сборщик мусора патологическим образом, что делает его O (размер кучи), может быть труднее понять, что происходит не так. Иногда даже так сложно, как исправить повреждение памяти.