Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???

Subject: Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: arvid_at_[hidden]
Date: 2012-07-18 17:38:00

Quoting Andrey Semashev <andrey.semashev_at_[hidden]>:
> On Wednesday 18 July 2012 10:30:46 Klaim - Joël Lamotte wrote:
> > On Wed, Jul 18, 2012 at 7:29 AM, Joel Falcou <joel.falcou_at_[hidden]>
> wrote:
> > > As for Pooling, there is still some use cases on embedded systems where
> > > you are required to pool some Mb at the beginning of the applications
> then
> > > you want to go through normal allocator/container design to access it.
> Gb
> > > of RAM on COTS computer are not the only use case around ;)
> > 
> > Exactly. For example, for high performance video games on any console,
> > there is no way you will avoid to have to pool memory in a way or another.
> > It is possible to not do this, but in most actino game context it is not
> > acceptable to have slow down because of allocations (though there are
> > diverse ways to fix this, pooling memory is a general one).
> 
> Ok, but that implies that the pool has to be at least as fast as the system 
> allocator. Which Boost.Pool isn't. I admit, I am no game developer, but 
> wouldn't be a fast allocator over a non-swappable memory region be a better 
> solution?

I would be surprised if boost.pool is slower than a typical system allocator.
I wonder if you're referring to ordered_alloc() and ordered_free() (which
clearly are very slow and probably over-used).

A very simple test of boost.pool [1] in 1.47 suggests that it is in fact faster
than the system allocator (on Mac OS X 10.7.3).

$ g++ -O2 -DUSE_BOOST_POOL=1 -IDocuments/dev/boost_1_47_0/ test.cpp
$ time ./a.out 

real	0m0.422s
user	0m0.406s
sys	0m0.003s

$ g++ -O2 test.cpp
$ time ./a.out 

real	0m7.065s
user	0m6.505s
sys	0m0.021s

> > Also, and it's very important: budgeting memory is a very important
> > practice in some very high performance games.
> 
> Good point, that might be a useful feature.

Another use case is when you're planning on allocating a very large number
of a specific object. Relying on the system allocator, you may end up in
a slab that holds allocation some tens of bytes larger than your actual
object. If you allocate a few million of them, the extra memory use may
become significant, as well as the potentially wasted L1 and L2 cache
caused by not having your objects be packed back-to-back in RAM.

> > Andrey Semashev  said:
> > > There is also an option to repurpose the library. Pooling raw memory may
> > > not
> > > be that needed today but pooling constructed objects is another story.
> > > More
> > > than once I had cases when constructing an object, including collateral
> > > resource allocation and initialization, is a costly operation and it is
> > > only
> > > natural to arrange a pool of such objects. While in the pool, the
> objects
> > > are
> > > not destroyed but merely "cleaned". An object can be retrieved and
> > > returned to
> > > pool multiple times, which saves the costly initialization. I could use
> a
> > > framework for building such pools. I think this is the most productive
> way
> > > of
> > > development of the library.
> > 
> > I was thinking is that mostly the Object Pool of Boost Pool was basically
> > what you describe? At least on the purpose, maybe not very efficient in
> the
> > implementation.
> 
> It creates and destroys objects within the pooled memory. Not much different
> from a raw memory pool.

My understanding is that the main complaint with the object_pool in
boost.pool is that when it constructs a new object, it uses
ordered_malloc() instead of just malloc() (not the system function, the
member of boost::pool).

Personally, this has forced me to just use the raw boost::pool and manually
call constructors and destructors. This seems like a trivial fix to make
to the object_pool type, but I'm not entirely sure why this decision was
made in the first place, perhaps there is a good reason.

-- 
Arvid Norberg
[1] http://codepad.org/vGuWLi0i