Subject: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-07-17 14:35:40
As one of the last people to try and do any maintenance of Boost.Pool I feel
I should try and start some discussion here on it's future.
First off some random thoughts based on my last experiences with this
* It should be simple, but it's confusing. In particular the difference
between ordered and unordered pools is not particularly intuitive, but IMO
the distinction between the various components, and what should be used
where is also poor.
* I believe the decision to support both ordered and unordered pools in the
same interface was a mistake. At the very least it's potentially error
prone in use, but it's also inefficient. It looks to me that this, along
with the allocators provided, were a classic case of feature creep
post-review. I'm sure they sounded like good ideas during the review, but
in practice a smaller more tightly focused library might actually be better.
* It's not clear that the claimed performance improvements are actually
there in practice (any more). This is partly due to compiler and std lib
improvements, partly due to feature creep in Boost.Pool. Some bug fixes
have had a negative effect too - however needed they may have been for
* Many of the existing bug reports were deliberately left "in limbo" because
there was no obvious/easy way to fix them without compromising Boost.Pool's
core mission (providing fixed size blocks of memory really fast).
* There have been many changes to the standard, compiler technology, and to
Boost's best practices since the library was designed, many of which would
result in a different design today, but also different requirements today
(per instance allocators in containers for example).
* In no way do I want to be lumbered with maintaining Boost.Pool and in any
case I don't believe it's really fit for purpose any more .
So..... in an ideal world, I'd like someone to step up to the plate and
design it's replacement.... yes a whole new Pool2.
Off the top of my head, here's my wish list:
* There should be a very small, very focused (i.e. fast) core that provides
fixed sized blocks of memory. Nothing more.
* Thread synchronization when needed (template param?) should be via
lockfree programming wherever possible. Indeed a simple pool like this, is
pretty much the poster child for lock-free-programming. And of course we
have Boost.Lockfree now.
* There should probably be a heap implementation for variable sized
allocation requests. I'm assuming that this can't be done lockfree(?).
* Allocators: both singleton and stateful allocators should be provided
(templated on pool type?). But there's a trick here: many containers only
allocate fixed size blocks, but we have no way of knowing what that size is
upfront at compile time. Connecting the allocation request to the correct
pool interface in an efficient manner is pretty tricky here, especially if
99% of allocations are of fixed sized, but there are a few odd-sized control
blocks also allocated. In any case, all allocations should come from the
same underlying block of memory, even if they're for different types/sizes.
* Both pools and allocators, should be able to accept a single fixed sized
block of memory (from wherever) and divide it up to clients. A good example
for this use case is an arena-allocator: a stateful allocator whose memory
all comes from the stack, no thread synchronization required. Containers
using such types can be blisteringly fast compared to regular allocators,
particularly when using a scoped container for just a few manipulations.
Ideal for use with C++11 containers or Boost.Container.
Hopefully others will chime in here with their requirements as well.
Cheers all, John.
1) This doesn't preclude applying *trivial* fixes to Boost.Pool, but I
genuinely believe that big changes are more likely to be counterproductive
at this point.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk