| News | Features | Interviews |
| Blog | Contact | Editorials |
| Real world comparison: GC vs. manual memory management |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-06 21:32:49 |
| "During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the D-Programming language. It was created within 3 Months time and allows multiple players to play deathmatch over local area network. All of the code was written with a garbage collector in mind and made wide usage of the D standard library phobos. After the project was finished I noticed how much time is spend every frame for garbage collection, so I decided to create a version of the game which does not use a GC, to improve performance." |
|
| RE[4]: yes... but why? |
| By dorin.lazar on 2012-09-07 09:58:52 |
|
> Performance outside of Databases and Games and sometimes embedded systems and web server is mostly not relevant today. You might be amazed, but performance matters. On the mobile phones, where it saves batter, on the server, where it's not always easy to add extra RAM or processing power. That 10% can be vital. Performance matters, all the time. |
 - Score: 2 |
| RE: Comment by kwan_e |
| By Neolander on 2012-09-07 10:04:38 |
|
> I like C++[11] (and C99 onwards) in that it makes it more easier never to have to dynamically allocate memory in the first place. Even in Java, objects with local lifetime tend to be optimized by stack allocation rather than dynamic allocation anyway. I was wondering about that recently : don't you run into stack overflow problems when you try to allocate everything on the stack including large arrays ? I know that stacks can be dynamically grown by some OSs, but surely at some point the top of that huge stack must hit something in the process' virtual address space right ? Now, if the language is smart enough to dynamically allocate large objects under the hood and still manage them like stack objects (i.e. silently liberate them when leaving the scope of the mother function), that's a different story. Edited 2012-09-07 10:15 UTC |
| - Score: 1 |
| Targeting programs for GC |
| By wigry on 2012-09-07 10:46:38 |
|
When one programs in a language which uses GC, then one must keep it in mind that the lessa garbage you create the less garbage has to be collected. For example Java is one of the most widly used GC language and EVERY java programmer must read the book Effective Java. That teaches you to see the problems that can introduce huge performance impact. Typical thing is the strings and other temporary vairables greated behind the scenes abnd thrown away just a millisecond later. If you would elliminate such things with constants your program wouldalready get 25% performance boost. So Manual memory management is not a good answer for GC issues. It is the attitude of the programmer that makes problems. |
| - Score: 2 |
| RE[2]: Comment by kwan_e |
| By kwan_e on 2012-09-07 10:48:46 |
|
> I was wondering about that recently : don't you run into stack overflow problems when you try to allocate everything on the stack including large arrays ? I know that stacks can be dynamically grown by some OSs, but surely at some point the top of that huge stack must hit something in the process' virtual address space right ? As I understand it, the theory and data suggests that most objects have a very short lifetime - in fact the life time of a function - by which time the stack space would be reclaimed by the function exiting. C99 introduced variable length arrays, but the C++ equivalent (vector and bounded arrays) often does dynamic allocation under the hood. So a vector on a stack is quite small - probably just a little more than a pointer and a length. The vector object cleans up the dynamic array underneath when the stack unwinds, either through a normal function exit or an exception being thrown (either directly, or by the environment). C++ library containers also allows you to supply your own allocator so you can customize a vector to only allocate storage from a limited pool. That also provides another advantage in the form of memory allocation speedups. > Now, if the language is smart enough to dynamically allocate large objects under the hood and still manage them like stack objects (i.e. silently liberate them when leaving the scope of the mother function), that's a different story. This is what RAII basically is, except it's not the language itself, but the language allowing libraries to be written that behaves in the manner you're talking about. |
| - Score: 2 |
| RE[5]: yes... but why? |
| By moondevil on 2012-09-07 10:56:00 |
|
On mobiles, Objective-C is moving to ARC (reference counting) and WP8 is having C++ with the CX extensions which make use of reference counting, alongside the usual .NET runtime. On the Android, while you can make use of the NDK, actually the whole userspace is Dalvik VM based, even when calling the APIs from C or C++. So the only way to avoid the GC is by using the NDK only APIs, which restrict you to games which don't interact with another applications. |
| - Score: 3 |
| RE[6]: yes... but why? |
| By dorin.lazar on 2012-09-07 11:08:14 |
| Yes, but even with this in mind, performance matters. I wasn't talking about GC anymore; GC can be a performance improvement for a lot of use cases, including most UI bound mobile software |
| - Score: 1 |
| RE: Comparison conclusion: use GC everywhere! |
| By renox on 2012-09-07 11:28:48 |
| Note that his figures are useless because I suspect that they are averages, for real time responsiveness what you need is worst case execution time not averages. |
| - Score: 2 |
| RE[3]: Comment by kwan_e |
| By Neolander on 2012-09-07 11:45:24 |
|
Well, variable length arrays are indeed a new feature to C99, but RAII in library form is older than C++11 so I don't see what the new release brings there. Edited 2012-09-07 11:49 UTC |
| - Score: 1 |
| RE[4]: Comment by kwan_e |
| By kwan_e on 2012-09-07 12:27:34 |
|
> Well, variable length arrays are indeed a new feature to C99, but RAII in library form is older than C++11 so I don't see what the new release brings there. I did put the "11" in brackets. In some forms of BNF, it means optional match. |
| - Score: 2 |
| RE: Targeting programs for GC |
| By zimbatm on 2012-09-07 13:25:11 |
| Agreed. Also targeting the points where most of your garbage is created, you can try to re-use existing data structures instead of re-allocating them on each call. That's a form of manual memory management that is used in GC languages like Java. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |