This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]