GC performances

[Craig Black]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:fie98d$8ed$1 at digitalmars.com...
> 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

The modern streamlined Java GC may win against an archaic manual memory 
allocator.  However, I don't think it could possibly outperform a modern 
manual allocator like nedmalloc.  I think that D should include nedmalloc in 
the standard library.  This would put D at the top of the list in this 
benchmark.