GC performances

[Sean Kelly]

Craig Black wrote:
> "BCS" <ao at pathlink.com> wrote in message 
> news:ce0a33432639b8c9fe730ad8498a at news.digitalmars.com...
>> Reply to Lutger,
>>
>>> Another interesting thing here is that the Java version beats all
>>> other languages too, including the ones with manual memory management.
>>> But it does cost a lot of memory.
>>>
>>> I would guess that this is an ideal case for a copying garbage
>>> collector? I wonder how much of an improvement such a GC will have in
>>> normal applications, and how hard it will be to implement in D.
>>> Another concern is what changes are needed in client code to work
>>> nicely with a copying GC.
>>>
>>> But this example does show how relative these microbenchmarks are.
>>> After all, it costs the Java version more than ten times the memory to
>>> outperform D, how will that affect the speed of a complex application?
>>>
>>> btw. I tried implementing this with a freelist, as suggested by the
>>> article at the digitalmars site, but it was slower than manual memory
>>> management. Might be because the code for allocation wasn't inlined
>>> for some reason.
>>>
>>> Likely not the intent of the benchmark, but an array based
>>> implementation could be faster here.
>>>
>> I wonder how fast it would be to just malloc a huge block of ram and use 
>> this for your memeory allocator:
>>
>> void* hugeBlock;
>> //void* end;
>>
>> T* Allocate(T)()
>> {
>>  T* ret = cast(T*) hugeBlock;
>>  hugeBlock = cast(void*) (&ret[1]);
>>  //if(end < hugeBlock) *(cast(int*)null) = 0; return ret;
>> }
>>
>> as long as you don't run out of ram, it will be real fast. :)
>>
> 
> Yes this is very fast but causes huge amounts of fragmentation and thus 
> inefficient use of memory.

It's not even necessarily that fast.  In the research I've seen, custom 
allocators are almost always outperformed by the default allocator for 
general use.


Sean