RE: following up on speed

["Anton van Straaten" <address@hidden>]

> Of course, my experience could be
> heavily skewed...have people here seen a lot of C/C++ projects play with
> different allocators or tuning strategies? Has anyone seen real use of
> C++'s ability to let your write custom object allocators?

Although most projects don't develop their own allocators, in my experience
it's pretty common to plug in a different allocator.  There are enough
allocator implementations out there, both free and commercial, to indicate
that this isn't a rare activity.

"Recently", the Boehm GC has become popular (I assume "everyone" already
knows about it, but FWIW: http://www.hpl.hp.com/personal/Hans_Boehm/gc/).
It provides conservative GC for C and C++, via malloc & new replacements.

There are plenty of other allocator replacements, though.  SmartHeap
(http://www.microquill.com/smartheap/index.html) is one commercial example.

Then there are special-purpose allocators, like Hoard
(http://www.cs.utexas.edu/users/emery/hoard/), for multiprocessor systems.

In light of this, when you say:

> Given the infrequency of malloc replacement and tuning, I'd suggest that
> it's a perfectly fair comparison to compare glibc's standard allocator
> against a modern and widely used scheme (say PLT scheme for example).

...I would suggest that this might be valid if you're comparing performance
between "average" projects, but on projects where allocator performance is
considered an issue, it would be misleading not to compare using the best
available allocators for a given language.

Since more than one GC'ing language has implementations that rely on the
Boehm collector at some level (Scheme comes to mind - PLT, Bigloo...), you
could actually keep the underlying collector constant between languages.
That ought to be a pretty fair comparison, but of course the GC'ing language
wouldn't get to show off any benefits that e.g. a generational collector
might provide.

Anton