[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: following up on speed



I can't speak for what people were expecting in 1980, but I remember Will 
Clinger creating a stir at one Lisp & Functional Programming Language 
Conference (I forget the year).

My recollection is that Will made the statement that, depending on the 
benchmark, you could get Scheme and C programs to be 10x performance of the 
other (most of the time they had about the same performance).  But there were 
benchmarks where C was 100X slower than Scheme!

When I asked him about this, he said the performance was due to GC.  The 
programs were "malloc intensive".  

If you know about how Malloc/Free are implemented (e.g. power of 2 buddy 
system with boundary tags), this makes sense.  When searching for a free 
block, you may chain through a number of links.  When freeing, you typically 
check the block tags on each side of the now-free block in order to coalesce 
free regions.  Thus you may execute many a hundred instruction for a  Malloc 
or Free call.

Contrast this with GC, where you just bump a pointer to allocate memory (in 
many cases only doing a bounds check at procedure entry).  You never touch 
dead objects, so the amortized cost of Free tends toward zero.

There was also a famous study (I believe with Cedar/Mesa) which showed 40% 
extra development time was taken up with memory issues when manual memory 
management was used vs automated memory management.

So my guess would be that the argument is that GC is more cost effective than 
managing memory manually.  [I made the argument in a paper in 1989.  I 
suspect there must have been others which made the argument much sooner].

$0.02,
-KenD

On Monday 15 July 2002 06:13 am, Bruce Lewis wrote:
> This prods me to ask a question that's been on my mind.  It's about GC
> advocacy in, say, 1980.  At that time, memory management with
> malloc/free was clearly more performant.  Did GC advocates at that time
> envision research that would eventually make GC as performant or more
> performant than malloc/free?  Or did they argue that advantages of GC
> outweighed the performance disadvantages?
>
> If it was the latter, we can be thankful they weren't so obsessed with
> performance as to abandon GC at that time.  On the other hand, we can be
> thankful that other people *were* sufficiently obsessed with performance
> to do all that nice research.