[gclist] Fast-allocating non-copying GC's

[fjh@cs.mu.OZ.AU]

David Chase writes:
> 
>[someone writes:]
> > > But, no matter where you allocate continuations, no matter
> > > how much to try to be clever in the compiler or whatever,
> > > some population of your programs by some number of users
> > > will exhibit high allocation rates.
> 
> The statement above is uninteresting from an engineering point of view
> -- there will always be outliers in any population, and some of them
> will always be dissatisfied with the biases built into any system.  If
> you don't talk numbers, it is true, but so what?  It just doesn't
> matter.

and then later in the post remarks parenthetically

> It was
> part of an effort to boost some benchmark numbers for a former
> employer's compilers.)

Yes, getting good benchmark numbers is important, even if it is only
for marketing or "political" purposes.  Many small benchmarks allocate
at a pretty furious rate.  That's one of the reasons
why it is good to have cheap allocation, especially if the
systems you are competing against have cheap allocation.
(I can only recall one complaint about the performance of the code
generated by the Mercury compiler -- that complaint was about
its performance on the naive reverse benchmark, one of the smallest,
most allocation-intensive benchmarks you could imagine.)

-- 
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
"No Bad Religion song can make your life complete" -- Bad Religion.