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."
Permalink for comment 534163
To read all comments associated with this story, please click here.
RE: GC is for scripting
by butters on Fri 7th Sep 2012 01:52 UTC 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