Linked by Thom Holwerda on Thu 6th Sep 2012 21:32 UTC, submitted by MOS6510
Benchmarks "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."
Thread beginning with comment 534169
To view parent comment, click here.
To read all comments associated with this story, please click here.
yes... but why?
by sergio on Fri 7th Sep 2012 03:21 UTC in reply to "RE: Comparison conclusion: use GC everywhere!"
sergio
Member since:
2005-07-06

Easier or not, the point is: memory management will be in the hands of the programmer. Why should we want that? 10% performance increase?

I prefer outsource memory management to a bot and use the expensive programmer's time to do something else.

Reply Parent Score: 0

RE: yes... but why?
by ebasconp on Fri 7th Sep 2012 03:36 in reply to "yes... but why?"
ebasconp Member since:
2006-05-09

I prefer outsource memory management to a bot and use the expensive programmer's time to do something else.


That comment is almost totally accurate. I say ALMOST, because:

1. The programmer still must handle the memory at some extent in managed languages: he needs to make sure that his unused objects are not being referenced for any reference, he needs to use weak references or he needs to call explicitly to the garbage collector [I remember I had a problem with a behavior similar to a memory leak in C# that occurred because my big array was stored as a 2nd generation object, so the garbage collector did not clean it in a timely fashion; or remember having some "loitering objects" in Java because I forgot to remove some listeners after my frames were closed].

2. Though memory is handled automatically by the garbage collector, other resources are not, so, they still need to be managed by the programmer (file handles, registry handles, database connections, window handles, locks, etc. etc.). This inconsistency makes me crazy because you need to call .Dispose() explicitly or need to enclose your code in a "using" statement to free system resources (but not memory). Handling all resources in a good way has the same complexity that handling memory. Using best practices in C++ avoids this problem because any system resource (including memory) is handled automatically and in a deterministic way using the RAII pattern.

3. Real good programmers will be productive no matter the language they will code on.

Edited 2012-09-07 03:55 UTC

Reply Parent Score: 6

RE[2]: yes... but why?
by Nelson on Fri 7th Sep 2012 04:34 in reply to "RE: yes... but why?"
Nelson Member since:
2005-11-29

1. The programmer still must handle the memory at some extent in managed languages: he needs to make sure that his unused objects are not being referenced for any reference, he needs to use weak references or he needs to call explicitly to the garbage collector [I remember I had a problem with a behavior similar to a memory leak in C# that occurred because my big array was stored as a 2nd generation object, so the garbage collector did not clean it in a timely fashion; or remember having some "loitering objects" in Java because I forgot to remove some listeners after my frames were closed]."


This is generally a lifetime issue and not really a memory leak, though it can look and quack like one. Especially with event handlers, once the event source itself goes out of scope, any listeners with zero references thereafter will be collected.

So sometimes not unregisering event handlers manifests itself as a memory leak, or sometimes it just lives on a little longer than usual. Makes it quite annoying to track down at times.


2. Though memory is handled automatically by the garbage collector, other resources are not, so, they still need to be managed by the programmer (file handles, registry handles, database connections, window handles, locks, etc. etc.). This inconsistency makes me crazy because you need to call .Dispose() explicitly or need to enclose your code in a "using" statement to free system resources (but not memory). Handling all resources in a good way has the same complexity that handling memory. Using best practices in C++ avoids this problem because any system resource (including memory) is handled automatically and in a deterministic way using the RAII pattern.


If you neglect to dispose of an object, eventually the finalizer is called and the resources are freed. But "using" makes this mostly a non issue.

3. Real good programmers will be productive no matter the language they will code on.


Completely untrue.

All in all, I find dealing with the nuances if even modern c++ to be more if an annoyance than an empowerment.

Reply Parent Score: 4

RE: yes... but why?
by dorin.lazar on Fri 7th Sep 2012 04:35 in reply to "yes... but why?"
dorin.lazar Member since:
2006-12-15

Easier or not, the point is: memory management will be in the hands of the programmer. Why should we want that? 10% performance increase?


No, we're talking here about a competent that was able to think about the time the garbage collection eats from his run times.

The programmer that takes garbage collection for granted usually gives much worse times. Think about 100% or 200%. Why? Because someone that doesn't keep in mind the metal under the framework (s)he uses will never be able to understand what a good trade-off is.

I prefer outsource memory management to a bot and use the expensive programmer's time to do something else.


Well, outsourcing will not make you stand out for long. And the quality of a programmer lowers in time as he is used to do it the easy way. In the end, there's a reverse effect of this 'doing the easy way' - in which with the tools the programmer knows (because the lower level will be inaccessible) he will have to do fine-grained work. It's like picking needles with a boxing glove; the framework being a boxing glove, it looks nice and shiny.

But keep in mind. 80% of any project is doing the last 20%. And the last 20% IS picking needles. Or you can deliver 80% of your product, and hope that you'll fool your client next time too. That's what most businesses do today in the western world, so I guess you may be Ok.

Reply Parent Score: 1

RE[2]: yes... but why?
by lucas_maximus on Fri 7th Sep 2012 08:58 in reply to "RE: yes... but why?"
lucas_maximus Member since:
2009-08-18

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.

Reply Parent Score: 3

RE[2]: yes... but why?
by JAlexoid on Fri 7th Sep 2012 14:44 in reply to "RE: yes... but why?"
JAlexoid Member since:
2009-05-19

Well, outsourcing will not make you stand out for long. And the quality of a programmer lowers in time as he is used to do it the easy way. In the end, there's a reverse effect of this 'doing the easy way' - in which with the tools the programmer knows (because the lower level will be inaccessible) he will have to do fine-grained work. It's like picking needles with a boxing glove; the framework being a boxing glove, it looks nice and shiny.


The best programmers are lazy programmers(the essence of DRY principle). Outsourcing memory management has always been the trend. First it was manual, then bare metal, then OS'es managed it and now runtimes manage it.

And needles today are mostly in the form of business requirements, not getting that extra 1ms. But then again, you can actually squeeze those 1ms out of almost any system.

Reply Parent Score: 3

RE: yes... but why?
by l3v1 on Fri 7th Sep 2012 06:50 in reply to "yes... but why?"
l3v1 Member since:
2005-07-06

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.

Reply Parent Score: 4

RE[2]: yes... but why?
by moondevil on Fri 7th Sep 2012 07:30 in reply to "RE: yes... but why?"
moondevil Member since:
2005-07-08

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.

Reply Parent Score: 4