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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-07-18 04:42:47

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?

> 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.

> 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.