I'm a C++ programmer who hates garbage collection on general principle, but I have to say: 20% of CPU time spent in memory management isn't all that unusual (especially in software that hasn't been optimized), whether or not that memory management is automatic garbage collection or manual.
I never understood the need for Garbage Collectors.
In my opinion, the difficulties of memory management are extremely overrated. I write code in C/C++ for almost 20 years and I never encountered a difficult bug that would have been avoided with a Garbage Collector.
If a coder really has a hard time with manual memory management it means he can't really code, this is a beginner problem...
Arguably garbage collection is a huge boon to productivity though. I agree about the first two, but I think the whole memory allocation debate is too contextual to be an issue in the general case. Big projects tend to have customized memory allocators which make most benchmarks usefulness dubious - that and reference counting can be nondeterministic too (you deallocate an object triggering a huge chain of frees).
With C++ since C++11, there is little need for garbage collection. I haven't written a manual memory "new" or "delete" in years, thanks to unique_ptr (which in my benchmarks is somehow also faster than manually managing the memory).
It's not a particularly controversial statement in the context of games. Many commercial games are still developed entirely or primarily in non garbage collected languages like C++.
Even Unity which uses garbage collected C# for game code is still a C++ engine under the hood for much of the performance critical engine code.
Having worked in games and VR development for many years I can say that memory management was not a major problem in C++ and for tricky areas of memory and resource management like GPU memory garbage collection doesn't generally help you.
When it comes time to optimize memory usage and performance it's often easier when memory management is explicit, deterministic and visible as well as highly customizable than when you have to work with a garbage collector which is a bit of a black box and has a lot of non deterministic and unpredictable behaviour.
Even after working for several years primarily in Unity with C# I still tend to prefer non garbage collected languages for games.
It does have a significant impact on performance. Especially for real time operating systems, micro controlles, and other embedded systems.
There for sure exists more then zero problems where garbage collection would be a worse solution then manual memory management. Even if you leave kernel development out of the equation.
When using certain styles in C or C++, memory management is really a tiny aspect you have to spend a tiny minority of your time thinking about -- but you gain so much determinism of execution in return.
I've been burnt by garbage collection killing my programs' performance many times -- having to tune the garbage collector has taken more time than just writing manual memory management in some cases!
Also, dynamic memory allocation and garbage collection just injects so much dynamism and uncertainty in your program's execution. I dislike it for the same reason I dislike dynamic typing. I want to be able to statically reason about the resource use of my program, just like I want to statically reason about any other aspect of my program.
My comments were about "big" self-contained projects for which it's worth it to have their own internal infrastructure and idioms etc. An example would be a compiler or an interpreter or a web server.
For smallish programs like what you describe, I agree that manual memory management can be decent overhead.
Many "big" projects try to reduce the memory management hassles by embedding an interpreted language such as Tcl or Lua for implementing non-performance intensive tasks.
I'm not advocating writing everything in C++, but with the right tools and in the right circumstances, the benefits of C++ can outweigh the annoyance of manual memory management.
Another reason I'm skeptical of garbage collection is because I read that unless you do things in a specific way you can have references hanging around in Java resulting in memory bloat.
A lot of people use garbage collected languages because garbage collection isn't an issue in their projects... until it is. And then folks who really have to deal with it, get to learn about their garbage collector and how to manage memory allocation in their apps.
But to some how claim that the productivity savings that folks get from deferring learning about the details about their language's garbage collector is somehow problematic, because in a subset of cases, you do care about object allocation and garbage collection is a pretty silly argument (especially in the face of the article's admission that garbage collection has won out).
Garbage collection for most people is a tool of convenience. When the tool becomes inappropriate, yes, people do have to learn how to optimize their code. None of this should shock us, or keep us from using garbage collectors.
Exactly. The other thing I get dirty look for from some people is when I tell them I've never done memory management. Every language I've worked in professionally has garbage collection, and I've also never done pointer arithmetic.
It seems a bit odd to complain that C++ doesn't support garbage collection. I mean yes, it's true, but... part of the point of C++ is to give you control of memory.
But you pay for it on the back side when it comes time to, heh, collect. There was a paper which suggested it takes five times as much RAM for a GC'd program to equal the coorespondng manual-allocator program in terms of performance: Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management".
If you care about performance you will avoid the garbage collector like the plague. Best to write it in C, C++, etc.
There are notable examples where garbage collection has both better throughput and latency than manual memory collection: persistent data structures come to mind, because in the absence of garbage collection, you have giant awful cascades of reference count manipulation any time a structure would get freed.
You'll never actually see anyone tout the benefits of using GC for this, though, because the performance characteristics of persistent data structures are so horrendous compared to mutable ones, no one actually uses them in C++.
I was a C++ developer now working on a Go project. I'm always suspicious of garbage collection, but people say it is an exaggerated claim. Glad to hear someone confirm this.
I've used languages with and without garbage collection. Usually, manual is more difficult to write, automatic is more difficult to troubleshoot.
I would love to use a language that allows me to do both. Writing exploratory code is more convenient using automatic memory management. There are certain kinds of code that benefit from manual memory management.
I find appalling that people can't find a middle ground between forbidden and mandatory.
Is that really proper use of the term garbage collection? If you are doing memory management manually, it sounds more like the lack of garbage collection. Unless they were using an unsafe GC for C/C++?
Not really. One reason that you infrequently see C++ programs using garbage collection, is because the language includes some nice tools that mitigate many of the pain points that drive people to use GC in the first place.
If you're using C++ as its own language, you get many of the nice things that come with memory management in dynamic languages, but you don't have to pay for it at runtime (the inclusion of shared_ptr in C++0x is a great example of this, actually). If you merely use C++ as "C with classes" (I'm not saying that you do this...just generally), then you don't see this benefit of the language.
I agree with your non sequitur, but I think there is something there nonetheless.
I think Yossi Kreinin's main objection is not the absence of garbage collection in C++, but the fact that so many projects that could use garbage collection, don't.
Like "I need performance!" No you don't. "I really need performance!" My GC is just as fast as your malloc/free. "I don't use malloc/free, I have my own custom allocators, you ignorant Java programmer!" I just use manually managed arrays for that, and enjoy garbage collection for the rest of my data. "My environment can't afford me any GC pause!" My GC hardly pause, and it collects gigabytes of data. "But I know things about my data your GC don't!" OK, now you may have a point.
The performance difference between C++ and a well implemented native language with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely less than an order of magnitude. Your constraints must be real tight to force you to give up garbage collection.
In the vast majority of projects, not using garbage collection is a problem. If not with the language, at least with the community.
---
I think Yossi Kreinin don't object the knife itself. He objects the fact that people actually try to eat soup with that damn knife, spilling soup and cutting their tongue in the process. Sometimes, we do need sharp edges (for cutting meat). But for much eating activities, sharp edges are just a hindrance.
reply