Re: following up on speed

[Mike Salib <address@hidden>]

On Mon, 2002-07-15 at 23:39, Daniel Weinreb wrote:
> Well, if you're going to try to do benchmarking, aisde from all the 
> other issues
> that arise when we translate a program between C and Scheme, you should
> really use the best available malloc/free.  After all, if someone 
> "demonstrated"
> that GC is "slow" by using one of the slower GC's available, you 
> wouldn't consider
> that fair.


Actually, I think it would be fair. In my experience, many C/C++ coders
don't seem to think too much about allocation issues. Watching java
evangelists argue the benefits of GC has really lowered my esteem of the
average programmer: so many coders seem to believe that calls to malloc
and free cost only a few instructions and always take the same amount of
time (unlike those nasty nondeterministic GC operatoins...). Ha! As a
result, C/C++ folk tend to use whatever malloc that ships with their C
library.

One of the benefits of scheme (and friends) is that the system takes
care of memory allocation/deallocation for you, adapting to the
program's dynamic allocation patterns. While a good malloc
implementation will do OK for an average program, it is rarely optimal. 
In theory, a good C coder can tune their malloc implementation to match
their application's allocation behavior (dramatically improving
performance), but in practice this doesn't usually happen. One reason is
that malloc tuning involves custom recompiling of glibc (which is a
pain), and some knowledge about how allocators actually work. If you're
convinced that malloc and free take zero time (like those folks yelling
at java evangelists), then you're probably missing the knowledge part.

For example, the glibc malloc implementation is based on Wolfgang
Gloger's ptmalloc, which in turn is based on Doug Lea's malloc. It
inlcudes nifty debugging features and lots of tuneable options, but
those features are compiled out of most linux systems by default. You
can get them by compiling your own version of glibc, but it's not
exactly a common practice. 

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).
There's no reason to penalize scheme just because C/C++ offer mediocre
performance by default and make it so difficult to fix that few
programmers ever bother to do so. 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?

More info on glibc's malloc is available at
http://www.citi.umich.edu/projects/linux-scalability/reports/malloc.html

Best Regards,
Mike Salib