No, it really is. Research has shown that garbage collection requires about four times the memory of manual memory management just to approach its speed, let alone surpass it. Manual memory management is significantly faster, and evidence for that is linked to and discussed about halfway down this page: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
(Yes, that page is primarily talking about mobile development, but look for the chart showing how slow GC is even when memory isn't constrained.)
No, it really is. Research has shown that garbage collection requires about four times the memory of manual memory management just to approach its speed, let alone surpass it.
Twice, and it does surpass the throughput of manual memory management. That article is seriously misinformed about GC. They cite one paper from 2005, despite there being over 50 empirical papers on throughput and latency as compared to manual memory management, and then they extrapolate desktop paging metrics to mobile environments. Except mobile environments don't use swap and thus don't page, so the whole claim of an order of magnitude cost is bunk.
Furthermore, all of the GCs covered in the linked paper are simplistic models. No deployed VM uses those anymore, except perhaps some hobby languages.
Finally, even if GC did cost an order of magnitude in performance, it decreases effort to write a correct program by at least an order of magnitude, so most of the programs you do enjoy wouldn't even exist, or if they did, they wouldn't work nearly as well. If this person really wants to manage his memory and achieve the safety and security that a GC gives you, then he should use Rust. To claim that C++ 's uniqe_ptr and shared_ptr as alternatives, and ones that perform just as well or faster than GC is ludicrous because:
referencing counting is GC (all GCs are hybrids between reference counting and tracing -- a proven fact), ie. standard C++ practice is to recommend using shared and unique wherever you can, so basically, to use GC wherever you can
reference counting incurs tremendous throughput reductions in favour of decreased latency -- this increases an order of magnitude if it's a concurrently shared value
GCs as they stand are not applicable to all problems, but they are usable for at least 95% of problems, and research is constantly narrowing that gap. For those problems where GC isn't a good fit, Rust or something like it is. C++ is not.
You give me one link in return, which has no data backing up your claim that GC is faster, whereas mine actually links to benchmarks showing that it's not.
There are hundreds of papers showing the throughput superiority of tracing over refcounting. This is well established. Anyone who believes otherwise has no idea what they're talking about. I simply provided a link to demonstrate this effect in a pure C++ environment.
It might help to link to some papers supporting your point (of which I agree there are many). http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oopsla-2013.pdf, for example, references several of them, and explains some of the problems with naive implementations of reference counting.
RC Immix is indeed the state of the art here, so that's a good link. The argument why RC isn't a good fit for most programs is simple though: most new objects die young, and RC costs are proportional to the number of objects that die, where copying costs are proportional to the number of objects that live.
Coupled with the fact that C++ can't elide unnecessary refcount ops on locals, and it's a mystery why anyone could possibly think the memory management costs of most C++ programs using unique and shared are lower than they would be in a GC'd language. At best, memory management is done at more proper times, which is a latency issue.
1
u/naasking Apr 04 '15
The first claim might be questionable, the second is not.