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

Subject: Re: [boost] [pool] Thread specific pool allocator
From: Edouard A. (edouard_at_[hidden])
Date: 2009-09-14 12:57:29

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.

If you want to go further, go for concurrent/lockfree containers.

-- 
EA