GC performances

[Craig Black]

"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.