RFC: change default allocator to __mt_alloc from current pool allocator

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

[This issue is related but orthogonal to the other allocator issue(s)
being discussed.  For the record, I have no great opinion on that
matter other than it sounds good to comply with the standard...]

First of all, I have a minor observation: performance/allocator.cc
should really be tested without -pthread otherwise malloc_allocator
likely looks better than it should and the MT cases look relatively
better than they should.  It would be nice if the performance tests
did the same "work load" to make direct comparisons possible (i.e. an
iteration is not the same work load in the various allocator tests).
I also wonder if it is indeed OK to hot-start the tests rather than
start from scratch for each allocator (i.e. the calibration step
unfairly boosts the default allocator's number!).  I will probably
hack on these tests to address these issues unless the primary test
author would prefer to do so himself within the next few days (hint).

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.
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)