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: <emery at cs dot umass dot edu>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 21 Jan 2004 18:44:32 -0500
- Subject: Re: RFC on mt_allocator.h
> I'm not sure why you are casting this unwarranted aspersion on my
research
> integrity, but I really do not appreciate it.
Emery, I'm sorry you feel that way, but I think you're overreacting. A
critical remark about your research isn't necessarily an attack on your
integrity.
My interest in memory management is motivated by a real-world problem
that led to the adoption of Hoard and the use of a custom allocator, in
that order. In other words, your distinction between custom memory
allocators and alternate implementations of malloc/free has little
practical value. Linking with a different implementation of malloc()
and overriding new() are not that far apart in terms of programmer
time. Most of the time will be spent collecting and analyzing test
results, and the same goal motivates both activities. I appreciate the
academic justification for (temporarily) limiting your research to
custom memory allocators, but the Related Work section of a paper may
contain references to relevant results that aren't comparable, in the
strictest sense, to the one being presented. I thought this omission
was glaring, and I still do.
In the interest of brevity (relatively speaking), I'll limit the rest
of my response to the topic of allocator testing, since this might be
of interest to the libstdc++ mailing list. I acknowledge that I hadn't
read the newer Sun paper that compares libumem with Hoard until after I
criticized your work. I also admit to suspecting that the test used by
Bonwick/Adams was inadequate. On the other hand, I think virtually
every application written for the purpose of testing allocators is a
poor substitute for a real-world application, partly because these
tests are all CPU-bound whereas the most demanding scenarios involve
lots of events or blocking I/O.
In defense of the libstdc++ allocator tests: while they don't do a good
job of covering the various STL containers (a stated goal), I'd say
that coverage is adequate. An allocator that's good at allocating
std::list nodes is unlikely to be bad at allocating std::map nodes, and
vice versa. Nodes are nodes. Furthermore, since the tests already
produce results that guide development, it's difficult to claim that
they do not serve their purpose.
In defense of the producer-consumer test I proposed: at some point, the
current tests will no longer reveal important performance differences.
Your ASPLOS 2000 paper warns of the potential for blowup when the
producer-consumer pattern is used, and I claim that this pattern is
*commonly* used in the applications that are the most likely candidates
for memory management optimization. My test is admittedly inadequate,
but it's a step in the right direction.
Felix