Интересно, как влияет сборка мусора на эффективность использования кэша процессора?
Я так понимаю, что эффективное использование кэша завязано на то, как часто будут использоваться одни и те же участки памяти. Когда используется сборка мусора то повторное использование одного и того же куска памяти для новых целей возможно только после запуска GC. Последнее стараются отложить на как можно более поздний момент. Поэтому агрессивное выделение/освобождение объектов в определенных ситуациях должно приводить к постоянной перезагрузке кэша. Если реализация алгоритма на с++ допускает активное использование стека и при интенсивном создании/уничтожении объектов в стеке этот стек будет «топтаться на месте», то кэш может вообще не меняться.
С другой стороны данные, с которыми идет активная работа скорее всего были созданы в одно время и лежат в одном месте. Что хорошо, по сравнению с вариантом, когда используется malloc()/free(). В последнем случае сложно предсказать, где будут лежать данные после двух последовательных malloc() (При использовании GC данные почти наверняка будут лежать рядом).
Подводя итоги:
1. Поскольку полноценная и безопасная поддержка GC сильно ограничивает возможности использования стека, то реализации некоторых алгоритмов в языках с нативным GC будут всегда сливать по производительности в сравнении с реализацией на с++, так-как в последнем случае можно активно использовать стек для хранения объектов.
2. Если надо много работать с кучей (malloc/free), то GC покажет свои преимущества во всей красе, и по производительности, и по безопасности, и по удобству использования.
В интернете много разговоров про «ништяки» второго случая, и ничего про первый случай. Кто-нибудь может сказать что-нибудь путное по данной теме? Может я чего-то не понимаю и стек в реальных приложениях не дает больших преимуществ?
