Re: [boost] [pool] Thread specific pool allocator

Subject: Re: [boost] [pool] Thread specific pool allocator
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-09-14 10:20:58

Am Monday 14 September 2009 18:57:29 schrieb Edouard A.:
> On Mon, 14 Sep 2009 12:47:00 -0400, "James Bremner" <ravenspoint_at_[hidden]>
>
> wrote:
> > Yes.  This provided a significant performance improvement, however it has
> >
> > some serious drawbacks
> >
> >   a.. I experienced some crashes during testing
> >   b.. Commercial licensing is expensive
> >   c.. It 'hooks' system calls to malloc, a technique I consider dodgy.
> >   d.. It is a DLL, which I avoid since they result in endless
>
> configuration
>
> > management nightmares.
>
> I completely share your views on Hoard. I don't like the hook placed on the
> allocator and it's just too much expensive for an allocator that makes
> program crash.
>
> Have you had a look at jemalloc? It's the allocator from FreeBSD. That's
> what they use for Firefox. It needs some adjustments, I guess, to be
> transformed into a full fledged STL allocator but it's a nice start.
>
> http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
> http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/jemalloc.c
>
> > Gosh!  Did I suggest anything like this?  However, a well designed
> > multithreaded program will slow down, rather than speed up, on a
> > multi-processor machine when the standard memory allocator is used which
> > took me, at least, completely by surprise and mystified me for several
> > days.
>
> Sorry I misunderstood your mail.
>
> The main reason you get such a speed boost with a better allocator is
> because it can prevent (or at least reduce) false sharing and is able to
> allocate in different threads simultaneously.
>

this suggestion is very much depending on your use case, but boost::intrusive 
containers can be very helpful to avoid allocation at inappropriate points 
completely.
even if you need allocation at container insert, you can pool the allocation 
and put the unused nodes in an intrusive::slist in between.
that's very much like a pool allocator but avoids the problem of STL 
containers requiring a stateless allocator and thus avoids using a 
thread_specific_ptr, which also is quite expensive on some platforms.
boost::intrusive containers never allocate memory themselves.