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: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-07-18 05:05:09

On Wed, Jul 18, 2012 at 10:42 AM, Andrey Semashev <andrey.semashev_at_[hidden]
> wrote:

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

Sorry, I forgot to say that indeed the system allocator is not fast in
these embedded contexts (at least in my experience).
I think on PC if you don't want very high performance you can, as you
suggest, still get good enough performance for a game.
But on console most system will allocate memory very very slowly compared
to a PC under Windows.

By the way, what i mean here is that the pool ask the system to allocate
memory once, then the objects are created/destructed in it.
So if you use a pool, you should pay only for object creation/destruction,
not memory allocation.
That makes me think that maybe memory pools makes no sense when they are
able to grow. To me a memory pool is useful only on fixed size, whatever
the behaviour when this size is reached.

Also, games are notoriously famous memory consumers: it allocate a lot of
data to be ready to be used while the game is playing.
This is why there are "loading screens", that are slow if allocation of
each object separately is slow.
Having a memory pool (or several for different purpose) for a game session
allow both quick loading of data (because there is only copy/construction
of this data, not memory allocation)
and allows to destroy the memory pool when getting out of the game session.
This make the game very responsive when the player just want to end the
session and start another.

Just for info, to get you the kind of context some game are in: another
technique when even memory pools are not good enough is to have the game
session memory map in a file that is directly loaded in the memory and
ready to go once done.
That way, you avoid object construction too, but it require some specific
tools.

Then you have the case where you can't know what kind of data will be
present, because it depends on either the path taken by the player, or the
data sent by another system, like in the case of massively multiplayer
games where all the data is dependent on a remote system sending messages
saying what the create/destroy when.
In this kind of case, it is preferable to have one or several pools because
you will have to pay for creation/destruction, but you don't want to pay
for the allocation/deallocation associated. In particular when it happens a
lot.

I Hope it helps understand this context.

Joel Lamotte