Re: RFC: change default allocator to __mt_alloc from current poolallocator

[Stefan Olsson <stefan at xapa dot se>]

Loren James Rittle wrote:

> OK, on to the good news: We are thinking of changing the default
> allocator to __mt_alloc before the 3.4 release.  The ABI has already
> been changed.  For MT test cases, esp. on MP hardware, it performs far
> better than the current default allocator on studied platforms:
>
> i386-*-linux*
> i386-*-freebsd4.9
> alpha-*-freebsd5.2
> sparc64-*-freebsd5.2
>
> [For the record, the tested version is -r1.10 on mainline; i.e. not
> the latest version on the 3.4 branch.  So be careful if you want to
> test it yourself before commenting.  I did 'cvs update -j1.10
> libstdc++-v3/testsuite/performance/allocator.cc' within a 3.4 tree;
> and then bootstrapped and ran 'gmake check-performance'.]
>
> For single-threaded cases, it is sometimes far better than the current
> default allocator (e.g. with list<> on FreeBSD4/i386,sparc64),
> sometimes far worse (e.g. with list<> on FreeBSD5/alpha) and typically
> within a few percent (e.g. with vector<>).  I do think we would need
> to understand why it performs so bad on this one alpha machine.
Unfortunately I don't have access to an alpha machine - if someone can 
provide that or a hint of what may be the cause I'll be happy to dig 
into it!

> Can anyone report how it works on a Linux/alpha or PowerPC machine?
>
> If you know of any other cases where single-threaded performance is
> much worse with __mt_alloc, then please report it ASAP.
>
> Regards,
> Loren (on behalf of Benjamin and myself)
>  
With respect to this proposal [of making mt alloc the default allocator] 
I have bumped up the priority of documenting it's inner workings and 
"allocated" all of friday to complete a first version of this.

Brgds

/Stefan