Re: Allocator tuning parameters

[Dhruv Matani <dhruvbird at gmx dot net>]

On Mon, 2004-01-26 at 22:31, Matt Austern wrote:
> On Jan 26, 2004, at 1:33 AM, Dhruv Matani wrote:
> 
> > On Sat, 2004-01-24 at 01:48, Loren James Rittle wrote:
> > [...]
> >
> >> There is also the issue that the default pool allocator has some cases
> >> where its performance profile truly stinks (for single-threaded, we
> >> think it beats most per-platform malloc implementations; however I
> >> have test cases where that is not always true).  Since we never
> >> figured out the best way to set the default allocator on a
> >> per-platform basis, the compromise was to always allow one to disable
> >> the pool cache.
> >
> > I have a suggestion that may not be always feasable, because it 
> > involves
> > the client to instantiate an allocator explicitly.
> >
> > Firstly, to make this work, we need to make each allocator truly type
> > parameterized, meaning that some_allocator<int> and
> > some_allocator<float> will not be sharing pools. As I have mentioned
> > earlier, this would improve the efficiency too.
> 
> It would improve some kinds of efficiency for some usage cases, at
> the cost of making memory fragmentation worse.
> 
> The original HP STL used a single pool per container.  We changed
> it to use one pool per allocator instead, and this was generally 
> believed
> to be a huge improvement.

Yes. In cases where the individual internal blocks for each allocator
instance grow altenately (one after another), and then one pool suddenly
disappears, then there will be quite a few holes left in memory which
may not be used later. However, I would expect that if the size of the
individual internal pools be substantially large (4KB) or some standard
value that such that each instance grows by that same amount (currently
mt_allocator grows by slightly less than 4KB), then it is quite possible
that the allocator at the higher level (used by malloc and co.) be able
to handle such situations, and be able to avoid that sort of
fragmentation to some extent. Also, since memory greater than a certain
threshold is obtained by a call to mmap (for Doug Lea's malloc), that
memory need not be near the application's heap, so then the OS can map
and unmap memory easily.

If you read on (the previous message), the I have written that different
instances of the same allocator parameterized around the same type can
share their memory internally, so the problem may not be that bad after
all.

I have not done any extensive testing in this particular area, so I can
not really tell. What I have written above is just my hunch, so it is
quite possible that it is wrong, or may not hold in all cases.


-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/