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 534142
To read all comments associated with this story, please click here.
GC is for scripting
by Carewolf on Thu 6th Sep 2012 22:05 UTC
Carewolf
Member since:
2005-09-08

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

Reply Score: 1

RE: GC is for scripting
by grable on Thu 6th Sep 2012 23:08 in reply to "GC is for scripting"
grable Member since:
2006-11-24

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.

Reply Parent Score: 3

RE: GC is for scripting
by Treza on Thu 6th Sep 2012 23:20 in reply to "GC is for scripting"
Treza Member since:
2006-01-11

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

Reply Parent Score: 6

RE[2]: GC is for scripting
by ebasconp on Fri 7th Sep 2012 00:50 in reply to "RE: GC is for scripting"
ebasconp Member since:
2006-05-09

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.

Reply Parent Score: 3

RE: GC is for scripting
by Meor on Fri 7th Sep 2012 00:30 in reply to "GC is for scripting"
Meor Member since:
2006-09-29

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.

Reply Parent Score: 2

RE: GC is for scripting
by butters on Fri 7th Sep 2012 01:52 in reply to "GC is for scripting"
butters Member since:
2005-07-08

I'm sure you realize that your native code is running on an operating system which can block on memory allocations and unpredictably preempts your code to run other tasks and interrupt handlers. You're not running on bare metal. You have a runtime as well.

But more importantly, if you take all the time you would spend working on memory management and instead spend it working on your data structures and algorithms, then you're likely to end up with faster code. The high-level optimizations are more impactful than the low-level optimizations.

This guy seems to have done both, replacing generic garbage-collected data structures from a standard library with purpose-built data structures and manual memory management. Which accounts for a larger share of the the benchmark delta: the memory management or the data structures?

CPU-bound tasks are few and far between these days, and many of these tasks perform much better on GPUs via runtime interpreters in the device drivers. Most applications are IO-bound -- and also bound by the complexity of development and maintenance.

Interpreted languages are going to win in the long-run, because they are better positioned to help address the elephant in the room, which is the difficulty of writing code that scales on thread-parallel hardware.

Improvements in the Hotspot JVM, for example, extracted thread-level parallelism from existing code, and Google designed Go with garbage collection in large part because it greatly simplifies its concurrency primitives: goroutines and channels.

Reply Parent Score: 3

RE: GC is for scripting
by butters on Fri 7th Sep 2012 04:36 in reply to "GC is for scripting"
butters Member since:
2005-07-08

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:
2011-05-19

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: GC is for scripting
by moondevil on Fri 7th Sep 2012 07:28 in reply to "GC is for scripting"
moondevil Member since:
2005-07-08

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.

Reply Parent Score: 2