GC performances

[bearophile]

This Shootout page shows an interesting comparison between Java6 and D:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&lang=all

As you can see there are two D versions, here I have written the slow one (the fast D version uses manual memory management (MMM), the slow version leaves it to the built-in GC). I think my version is equal to the faster solution, that run on Java (it uses automatic GC), you can see both versions here:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&lang=dlang&id=0
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&lang=javaxx&id=2

The interesting thing is that despite the code being essentially the same, the D version run 9.1 times slower than the Java one.
Some notes:
- This shootout test is designed to stress the GC.
- From my experience on this demo, I think that speed difference (between that Java and the slow D version) is caused mostly by the GC, so the D GC is quite worse than the Java6 one.
- There the Java6 GC receives some hints from the programmer, those "-server -Xms64m" (but not -Xbatch, it disables background compilation) on the command line, I presume the D GC may someday accept similar hints.
- You may take a look at he memory used too: Java6 with those GC hints: 40.3 MB (the -Xms64m flag sets the initial Java heap size to 64 MB), D MMM: 4.7 MB, D with GC: 17.6 MB.
- The Java code shows how most people writes code, because manually managing memory is okay in a little benchmark like this, but if you have a very large system it's not easy to manage every memory usage by hand.
- There are even faster ways to solve this problem using D, I have seen that using a free list the code becomes even faster than the MMM one. And there are ways to speed that up too a lot.
- Today the source code of Java6 can be read, it's open source, so some of the ideas used by GC can be borrowed to the D GC (but it may require some work).

Bye,
bearophile