RE: [boost] Formal Review: Pool - Major question

From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-06 12:26:54

At 09:43 AM 12/5/2000 -0500, scleary_at_[hidden] wrote:

 >> The main rationale for adding pool allocation is that it is "very
 >> fast".
 >
 >Actually, the original intention for pool<> was to have an object that,
 >when
 >it goes out of scope, will call the destructors for any objects allocated
 >from it.  That is, a "poor man's garbage collector".
 >
 >Other uses special to pool also exist; for example, using sized_pool, one
 >may skip deallocation overhead completely.
 >
 >The idea for "pool" is to provide a set of interfaces that allow more
 >powerful and specific manipulation of memory, not to replace
 >std::allocator.

So it is really a documentation issue.  Although I admit to reading the 
docs sitting in an airport lounge, and may have just missed the mark.  Let 
me look again... Well, your lead sentence (in index.html) is "Pool 
allocation is a memory allocation scheme that is very fast, but limited in 
its usage."   That seems to imply speed is the primary consideration.

But you rationale above is quite clear.  I'd use it as the index.html lead. 

 >> Including std::allocator, do we really need three
 >> allocators?  Only if the proposed new allocators are significantly 
faster
 >> that std::allocator or each other in real applications.
 >
 >There are two other allocator interfaces under development, 
too.  Allocator
 >overkill?  Maybe we should provide one "pool allocator interface" that is
 >based on Generative Programming...

Yes, I'm afraid apparent "allocator overkill" will cause users (and the C++ 
committee, when it comes to standardization) to just throw up their hands 
and say this is way too complicated.  Generative Programming might well be 
away to deal with this, but that's something for rev 2.

 >> For example, inserting and then deleting a million random numbers into 
a
 >> std::set is a the simple test I would consider an approximation of a 
real
 >> application.
 >
 >On my platform (BCB5, Win32), the pool allocator is slightly *slower* 
with
 >this test.  This is due to a well-optimized STL (RogueWave's); each STL
 >container maintains a buffered free list that acts exactly like a 
pool.  So
 >using the pool allocator interfaces won't get you anything.  However, "It 

 >is
 >intended that a.allocate be an efficient means of allocating a single
 >object
 >of type T, even when sizeof(T) is small.  That is, there is no need for a
 >container to maintain its own 'free list'." [20.1.5, note 214].  Thus,
 >there
 >is no guarantee that other STL implementations will be so designed -- the
 >note quoted above seems to discourage it, so I suggest we keep the pool
 >allocator interface anyway.
 >
 >Also, IMO, it makes new container design simpler.  I have a sll container
 >(who doesn't?) that uses its Allocator in the Standard-recommended naive
 >way; it would greatly benefit from pool.
 >
 >> So I'd like to see Steve or others provide a simple test program that 
for
 >> each component in the pool library compares the speed of the pool 
library
 >> to the alternatives (new/delete or std::allocator as appropriate).  I'd 

 >> like to see boost members run the timings on their platforms and report 

 >> back the results.
 >
 >I'll put out a simple test program soon.  I'd like to see the results of
 >other platforms as well.

Thanks for the quick response.  I think the timings are still important, 
even though it turns out there is other rationale for including pool in 
boost.

--Beman