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 534157
To view parent comment, click here.
To read all comments associated with this story, please click here.
ebasconp
Member since:
2006-05-09

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.

Reply Parent Score: 4

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: 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: 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