| 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: Comparison conclusion: use GC everywhere! |
| By tanzam75 on 2012-09-07 05:57:29 |
|
> 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. Well, that's an optimizing compiler with GC, vs. a poorly-optimizing compiler without GC. He couldn't get the non-GC version to compile on the optimizing compiler. The argument is that if he'd gotten it to compile, then it'd show a similar performance difference Of course, if it doesn't compile, then it doesn't make his game perform any faster, does it? |
| Benchmarking |
| By tanzam75 on 2012-09-07 06:06:03 |
|
Benchmarks are very tricky things. Details can make all the difference. Thus, I would not necessarily take the student's results at face value, without investigating further. I don't know D, so I can only throw out some thoughts that come to mind from reading the blog post. Perhaps someone else could look through Github and check out the code? First, doesn't D have a generational garbage collector? (http://dlang.org/garbage.html doesn't say -- but it does approve of generational collectors.) The student says that he's collecting on every frame. Is he doing an ephemeral collection, or a full collection? 7 milliseconds seems kind of long for an ephemeral collection ... Second, what if he collected every 5 frames instead? He's collecting on every frame because he's paranoid about making the 60 Hz cadence. But he made it -- so he now has some room to experiment. He gets 7 ms of overhead by collecting on every frame, but what if he gets 8 ms of overhead by collecting every N frames? This would still make the cadence -- but save a lot of battery! (Suppose he frequently creates objects that are referenced in the next frame -- but that almost always die within N frames. Then he's incurring a lot of unnecessary overhead by forcing the collection on every frame.) Third, he just dove right in and completely removed GC. But did he really have to do that? Profiling-driven optimization tends to be amenable to the Pareto principle. 10% of the work might get you 90% of the benefit. Sometimes, tweaking 1 line of code gives you 90% of the benefit. The poor performance of the garbage collector might've been caused by just a few classes. Edited 2012-09-07 06:08 UTC |
| GC slow, oh no |
| By l3v1 on 2012-09-07 06:43:06 |
| So, GC is slow when doing complex stuff with lots of memory handling and threads. In other news, the sky is blue. Unfortunately I see this all the time these days when we have new students or fresh graduates coming to work for us. Real progress. Now, I don't dislike GC and the associated line of thinking, design and coding practices. But man, when they only know that and only use that, my hair's grayness transfer function just gets steeper. |
| RE: yes... but why? |
| By l3v1 on 2012-09-07 06:50:55 |
|
> Easier or not, the point is: memory management will be in the hands of the programmer. Why should we want that? 10% performance increase? Oh yeah. There have been occasions when I could've killed for another 10%. Also, in such occasions it's the code's coder who knows best how to squeeze out that additional 10%, not an outsourced code-monkey. > I prefer outsource memory management to a bot and use the expensive programmer's time to do something else. Well, can be nice for that expensive programmer, being able to say he's not responsible for memory management errors and leaks :) But your bot might be your doom. |
| RE[3]: GC is for scripting |
| By l3v1 on 2012-09-07 06:56:48 |
|
> No wonder he ran into performance problems (and memory leaks) when he took out the GC! Right, since high performance and non-leaking code can only be achieved by using a GC. I'd probably need a run to Rekall for that sentence not to make my head explode. |
| RE: GC is for scripting |
| By moondevil on 2012-09-07 07:28:26 |
|
> 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. You're right! That is why all major programming languages besides C, are now offering some form of automatic memory management, be it GC or reference counted based. |
| RE[2]: yes... but why? |
| By moondevil on 2012-09-07 07:30:33 |
|
Except in most projects better hardware will be cheaper than one month salary for a top programmer. So sadly in the corporate world, no one would care for those 10% gain thanks to better coders, and would rather invest in better hardware. |
| RE[2]: yes... but why? |
| By lucas_maximus on 2012-09-07 08:58:19 |
|
Way to miss the point. The whole point is and he is right, is that extra performance really worth the extra development time? If it isn't then it isn't worth it, it is a trade off that should be considered part of the development process. The other ridiculous argument about someone losing some skills because they did stuff the easy way is ridiculous. Most of the code I work with is pretty much WTF, because somebody wanted to do it the "clever" way. The lost productivity due to this is massive when making minor modifications. |
| RE[3]: yes... but why? |
| By Slambert666 on 2012-09-07 09:09:56 |
|
> Except in most projects better hardware will be cheaper than one month salary for a top programmer. Except in most cases today the program you write starts out at using 2% of total CPU and then you spend a month getting to 1.8% ... Performance outside of Databases and Games and sometimes embedded systems and web server is mostly not relevant today. |
| RE[3]: yes... but why? |
| By dorin.lazar on 2012-09-07 09:55:12 |
|
> Way to miss the point. The whole point is and he is right, is that extra performance really worth the extra development time? If it isn't then it isn't worth it, it is a trade off that should be considered part of the development process. There's always the question if the extra performance is really worth the time. That's for everyone to decide, their business, not mine. But sometimes it's too late to optimize. > The other ridiculous argument about someone losing some skills because they did stuff the easy way is ridiculous. A lot of people in software development forget about the psychological impact of the work that developers do. You might think that there's no impact, but please, think about it one more time. Give a senior developer menial tasks, and you shall have a mediocre experienced developer. Remember, a developer is as good as the job he does, not as the time he invested into the job. > Most of the code I work with is pretty much WTF, because somebody wanted to do it the "clever" way. The lost productivity due to this is massive when making minor modifications. No, I'm not talking about 'the clever way' to hell. I'm talking about skipping some of the essentials. People that never done a delete nor ever thought about memory consumption will have a hard time when such limits comes into place. I recently had a wtf moment, when someone was caching an entire table in memory, then copying the cache as a backup. His verdict was "sometimes it crashes, don't know why". There's a 'too stupid' too, not only 'too clever'. |
| News | Features | Interviews |
| Blog | Contact | Editorials |