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

Re: following up on speed

I agree that C and C++ programs usually take the standard alloc/free.
In fact, i've seen programs here that don't free at all.  I've also 
wondered about other costs, such as a subroutine copying a string passed 
into it.

I found "The Measured Cost of Conservative Garbage Collection" by Ben Zorn,
quite convincing.  His abstract concludes with

"C programmers should now seriously consider using conservative garbage 
collection instead of malloc/free in programs they write."

I think Java and C++ contributed to the acceptance of GC,
Java because it had GC, and C++ because it doesn't.

Increased exposure to other languages such as Perl, Python, and even 
functional languages has probably also helped to make GC "OK" in the main 


At 02:11 AM 7/16/2002, Mike Salib wrote:
>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
>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
>Best Regards,
>Mike Salib