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 534184
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: GC is for scripting
by butters on Fri 7th Sep 2012 04:36 UTC in reply to "GC is for scripting"
Member since:

Also it should be noted that while garbage collection may increase the cost of freeing memory, it can significantly reduce the cost of allocating memory. The garbage collector runs asynchronously, so trading for fast synchronous allocation is a good deal.

Most modern garbage collectors implement an algorithm in which reachable objects in a full memory region are copied to a free memory region in depth-first traversal order. The remaining objects are unreachable, so the whole region is freed, and the new region is populated with excellent spatial locality of reference.

Because the memory allocator understands the garbage collector, finding free memory is cheap and easy. Heap implementations like malloc have to do the hard work of scanning implicit free lists on allocate, where garbage collected heaps do the hard work in the background.

Reply Parent Score: 3

RE[2]: GC is for scripting
by tanzam75 on Fri 7th Sep 2012 05:49 in reply to "RE: GC is for scripting"
tanzam75 Member since:

Well, for ephemeral objects, then generational GC will speed up both allocation *and* deallocation. If it dies during its first collection, then there is zero overhead from the garbage collector.

It's actually the objects that survive a collection that incur the GC overhead, as they must be copied into the older generation.

There's a puzzling statement in the blog post that suggests the student may not have fully internalized this very counterintuitive fact:

... if you write code with a GC in mind you often do not think about the consequences when allocating memory, because the GC will deal with it. This often leads to highly imperformant code ... Comparision of TypeInfo objects in druntime is done by building two strings and then comparing those two strings. This will always leak memory and do a lot of unneccesary allocations which are a performance bottleneck.

But with a generational GC, it should not leak memory, and it should also not perform that badly. The temp strings should be ephemeral, and should die with no overhead. In other words, this is precisely the scenario that should perform faster with a GC than without a GC.

No wonder he ran into performance problems (and memory leaks) when he took out the GC!

Reply Parent Score: 1

RE[3]: GC is for scripting
by l3v1 on Fri 7th Sep 2012 06:56 in reply to "RE[2]: GC is for scripting"
l3v1 Member since:

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.

Reply Parent Score: 4