Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

[renoX]

Craig Black a écrit :
> "BCS" <ao at pathlink.com> wrote in message 
> news:55391cb32a83e8ca55bd841aba20 at news.digitalmars.com...
>> Reply to Craig,
>>
>>> Interesting article:
>>> http://lambda-the-ultimate.org/node/2552
>>> -Craig
>>>
>>
>> That test sounds bogus to me. The results for manual memory management 
>> are effectively unbeatable. I rather suspect that most program lose 
>> the last reference to memory about the same time you can tell it won't 
>> be used (so it's almost as quick as possible there) and it has no 
>> overhead at all including the accounting needed to keep track of the 
>> memory. Add back in the post processing time and then tell us the 
>> numbers!
>>
>> What I want to see is: rebuild a Java app with smart pointer or 
>> something, or how about spec a large function block as detailed as you 
>> can without knowing if you will be using GC or not and then implement 
>> it both ways (sever times by sever people). Then compare those.
> 
> If I understand the article correctly, I think you are missing the main 
> point of it.  It is not merely saying ,"We ran conclusive test: GC loses 
> to explicit memory management!"  They went much further than that, and 
> identified the primary bottleneck in modern GC implementations.  Namely, 
> that GC doesn't cooperate well with virtual memory.  GC typically scans 
> way more memory than the rest of the application, and consequently 
> causes the most cache misses/page faults.  This article is not bashing 
> GC.  I think it is indicating to us how we can best improve it.  Perhaps 
> some GC algorithm could be developed that is optimized specifically to 
> produce the fewer page faults and cache misses.
> 
> Thoughts?


The same authors have made a VM friendly GC, it is linked at the end the 
article..
http://lambda-the-ultimate.org/node/2391

The are two drawback of their GC:
1) The OS needs to be modified so that the VM and the GC communicate.

2) It is a moving GC, in the original paper they compares their GC with 
moving and non-moving variant and the moving one win.

For Java this isn't an issue, but for D it is: working with C's library 
wouldn't work if the GC is a moving one..

I don't know how to fix this one..

Regards,
renoX



> 
> -Craig
>