| 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." |
|
| GC is for scripting |
| By Carewolf on 2012-09-06 22:05:42 |
|
Seems like a smart student, but it can not be said often enough, since new programmers are coming out of out of school all the time who haven't learned it yet: Garbage collecting is for interpreted languages and short scripts, not for anything else. There is no reason to try to argue with this, or waste your time proving it over and over again. We have all been there and have had to learn and accept it, and it is not something better garbage collectors are changing. The only thing changing is how big programs you can build these days with interpreted or semi-interpreted languages. Edited 2012-09-06 22:06 UTC |
 - Score: 1 |
| Its a trade off |
| By Nelson on 2012-09-06 22:13:37 |
|
Garbage Collection is a balance between convenience and performance. The non determinalistic nature of collections means that without clever engineering, you can a hit a GC pause during something crucial like rendering. I think the author, while a fascinating article, threw the baby out with the bathwater. You couldve likely kept the GC and reduced collections by being more conscious to it, and employing various tactics like pooling to reduce collections or simply cleaning up hisoobject heirachies. You can go a long way before you abandon allocation safety. Of course, I don't know much about D's GC or if its even generational, but from a .NET POV, I've been able to reduce its impact while writing XNA games for Windows Phone (where the GC pauses can be even more devastating) |
| - Score: 3 |
| ... |
| By Hiev on 2012-09-06 22:28:09 |
|
Although is nice to see the numbers, ain't nothing most of us didn't know. Edited 2012-09-06 22:28 UTC |
| - Score: 3 |
| RE: GC is for scripting |
| By grable on 2012-09-06 23:08:15 |
|
> Garbage collecting is for interpreted languages and short scripts, not for anything else. Thats not entirely true though, there are some benefits to limited garbage collection for some data structures and certain language features. I would certainly want one when implementing closures in a language feks. |
| - Score: 3 |
| RE: Its a trade off |
| By JAlexoid on 2012-09-06 23:18:44 |
|
It's an interesting read, but it's a read about performance of D's GC mechanisms and developing without garbage. Not like it's a good comparison of GC vs non-GC. in all scenarios. You can get to a real time system with a GC'd platform, as long as you know how what is the longest part of the GC process and minimizing garbage in that area. |
| - Score: 2 |
| RE: GC is for scripting |
| By Treza on 2012-09-06 23:20:10 |
|
> There is no reason to try to argue with this Well, I'll argue. - Garbage collection is not directly related or "reserved" to interpreted languages and, of course, with JIT compilation... - All sorts of operating system structures are doing special forms of garbage collection. - There are all sorts of applications (which are often not games) where doing manual, precise memory deallocation is not practical. The only question is to build an ad-hoc garbage collector or use the general-purpose collector from your favorite langage. - There are some occasions where GC can be faster than manual memory management, because of memory fragmentation, cache thrashing... |
| - Score: 6 |
| Comparison conclusion: use GC everywhere! |
| By sergio on 2012-09-07 00:19:03 |
|
Well, the author don't tell us how much additional development time the manual memory management had taken. So I will take into account only performance: Best GC Version: 128.6 FPS, 7.72 ms frametime Manual Version: 142.8 FPS, 7.02 ms frametime This a 11% performance improvement for an unknown amount of additional work. And here We're taking about a worst case scenario for a GC: a game is 100% interactive and real time application. Even so We only lost 11% of performance. In other words: the max price you have to pay for using a GC is 11% performance loss. How much performance improvement would We had in a traditional online non-real-time system? 2%? How many memory leaks We "gain"? How many additional programmer hours would We have to pay? Hey, I'm think this study is the perfect apology of GC use. We have to use GC all the time even with games! |
| - Score: 2 |
| RE: GC is for scripting |
| By Meor on 2012-09-07 00:30:39 |
|
Bullshit. GCs are completely applicable in applications that are I/O bound or CPU bound; essentially GCs are great in any application where the GC drawbacks are acceptable. Most people don't write operating systems or drivers. |
| - Score: 2 |
| RE[2]: GC is for scripting |
| By ebasconp on 2012-09-07 00:50:03 |
|
> The only question is to build an ad-hoc garbage collector or use the general-purpose collector from your favorite language. Why would you build your own GC instead of improving your allocation mechanisms in manually managed memory? I consider the latter far simpler. |
| - Score: 3 |
| RE: Comparison conclusion: use GC everywhere! |
| By ebasconp on 2012-09-07 00:55:30 |
|
I do not know D, but C++ provides a lot of tools to deal with memory that make its handling easier (the simplest: RAII; the nicest: unique_ptr, shared_ptr, weak_ptr; the most complex but most powerful: placement new). Using RAII and smart pointers is almost as easier as writing anything in a GCed language; so I do not see why writing the version that manages memory manually could be hard. |
| - Score: 4 |
| News | Features | Interviews |
| Blog | Contact | Editorials |