4 ms·
Fans of GC claim that GC outperforms malloc() based on some studies that were done a long time ago. The argument is that repeated malloc/frees are less efficien
by zik 11y ago
Fans of GC claim that GC outperforms malloc() based on some studies that were done a long time ago. The argument is that repeated malloc/frees are less efficient than a bunch of GC allocs and then a single garbage collection.
The reality seems to be a bit different. In practice GC programs tend to use significantly more memory which can impact performance. And the trend towards low GC pause times costs additional CPU. Beyond that we're now using much larger multi gigabyte GC memory pools which can also lead to poor GC performance.
So overall people these days see lower performance with GC systems compared to malloc.
- kasey_junk 11y agoProve it.
- jeffsco 11y agoPlease cite some evidence. As a GC fan, I'm interested in this question. (In my opinion, GC is more than worth the cost.)
- velco 11y agohttps://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
- rurban 11y agoThey are only talking about slow, conservative, stop-the-world collectors there. They have to scan the full heap. You shouldn't compare apples with oranges.
- velco 11y agoI find the methodology of the research to be solid, the collectors to be representative of the different approaches in the field and the conclusions to be consistent with the gut feeling from experience: "With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%."
- pjmlp 11y ago> In practice GC programs tend to use significantly more memory which can impact performance In which language ? There are GC enabled programming languages with global and stack static allocation, for example Oberon just to cite one, which was on top HN a few days ago.
- pcwalton 11y agoMany of the claims that GC outperforms manual memory management compare running dlmalloc to allocate all data with a well-tuned generational garbage collector on something like the Da Capo benchmark suite. Naturally, they find that the ability to get bump allocation in the nursery of a good generational GC ends up outperforming a malloc implementation that was never really designed for that kind of workload. But the real question, in my mind, is whether a well-tuned systems-level program that uses stack, arena, and heap allocation with a good allocator like jemalloc ends up being better with a garbage collector. And it's really hard for me to see how that could possibly be the case. Performance-conscious systems programmers will use the stack as their nursery, gaining all the benefits of the nursery without the copying, tracing, or delayed reclamation. Modern mallocs like jemalloc or tcmalloc are incredibly good at minimizing fragmentation and satisfying requests quickly, using thread-local caches to avoid synchronization. Most of the time, the tenured generation needs the same bookkeeping that a modern malloc does, so you're not really gaining anything by using GC for that generation. And a GC always has some kind of mark or tracing phase (not to mention at least a write barrier if you want your pause times to be reasonable), which is pure overhead over manual memory management.
- pjmlp 11y agoYes, but in a language like Modula-3 you can have your "well-tuned systems-level program that uses stack, arena, and heap allocation with a good allocator", and still have a GC at your disposal. Sadly HP/Compaq killed the Olivetti/Digital unit and Modula-3 died, but its ideas can still be applied in modern languages, assuming similar capabilities.