GC performances

[Bill Baxter]

janderson wrote:
> 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?

Priorities?

--bb