This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: RFC on mt_allocator.h
- From: Felix Yen <fwy at alumni dot brown dot edu>
- To: bkoz at redhat dot com,stefan at xapa dot se
- Cc: libstdc++ at gcc dot gnu dot org,ola at xapa dot se
- Date: Tue, 13 Jan 2004 21:15:06 -0500
- Subject: Re: RFC on mt_allocator.h
Benjamin Kosnik writes:
> Please, I beg you, document this allocator.
I also beg. I'm new here, so let me introduce myself.
About two years ago, I was working on a communications server that had
a memory-related performance problem. We fixed it by switching from
the default (Microsoft) allocator to Hoard
(http://www.cs.umass.edu/~emery/hoard/). I felt that there was room
for further improvement in this area, and developed a recycling
allocator that's part of the server today. Each server process can
support 100,000 clients.
After losing my job and taking some time off, I thought it would be fun
to develop a more generic, open-source version of this allocator, so I
performed another cursory literature search, and discovered the GNU
pool allocator. I subscribed to this mailing list in 8/03 to learn
more about GNU allocator development. (I have to say that I am
extremely impressed by the way engineers collaborate on this project.
Yours is a model of professionalism that I wish my previous managers
had known about.)
A month later, I published my allocator in comp.lang.c++.moderated
(http://home.earthlink.net/~brimar/yalloc/). I wasn't bothered by the
lack of response, because free software rarely deserves anyone's
attention and this allocator is highly specialized. On the other hand,
I was quite annoyed when I discovered that I had overlooked significant
developments conducted by Jeff Bonwick. In 1994, he published an
allocator that's similar to mine, and in 2001, he (and Jonathan Adams)
extended this work to produce an allocator that is *very* similar to
mine:
http://www.usenix.org/publications/library/proceedings/usenix01/
full_papers/bonwick/bonwick_html/index.html. (There are significant
differences, but I don't understand them and have no way of comparing
performance.)
The point that I am trying to convey here is that allocator development
is a popular exercise, and one that lacks a well-publicized
documentation base so there's a lot of duplication of effort and
second-rate work. If you doubt my last claim, please read
"Reconsidering Custom Memory Allocation" by Berger et al
(http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf). Worth
noting: Bonwick's 2001 allocator comparison includes Hoard, whereas
Berger never refers to Bonwick's work. Guess which allocator won the
comparison? </intro>
At the very least, an allocator as sophisticated as the one you're
discussing should be accompanied by documentation that specifies its
intended applications and describes its design as well as its
limitations. I would also like to see a brief description of the
performance test(s) used to qualify the allocator. I realize that this
is a tall order, but any sane person who's shopping for an allocator is
going to look at GCC sooner or later.
I know someone on this mailing list made the point that the default
allocator should perform reasonably well in most cases. I strongly
agree. In fact, I think the distribution only has to provide obvious
alternatives like the version that supports debugging, allocators that
are used by the distribution itself, and maybe adaptors that facilitate
using user-supplied classes or global functions as STL allocators.
Since everyone seems to think that they're better off writing their
own, let them.
Felix