RFC: change default allocator to __mt_alloc from current pool allocator

[Stefan Olsson]

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