Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

[Craig Black]

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

-Craig