GC performances

[janderson]

Craig Black wrote:
> "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. 
> 

I agree.  Someone requested this ages ago.  I wonder why hasn't this 
been done yet?

-Joel