Re: Performance report (350MHz i686 configured as i386-unknown-freebsd4.8)

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

In article <20030624093641.GA15187@alinoe.com>,
Carlo Wood<carlo@alinoe.com> writes:

>> Run without -pthread: allocator.cc malloc  2433r 2163u    2s    0pf 
>> Run with -pthread: allocator.cc    malloc   426r  399u    1s    0pf 

> Huh?  Is there an explanation for this?

Hi Carlo,

Under the assumption that this is related to the issue that I wrote a
complete analysis in the past: some platforms have a malloc
implementation that kicks GCC's pool allocator in the butt under
certain access patterns (and, to be fair, some access patterns where
GCC's pool allocator always wins).  Now, I have not studied this exact
test to learn why the unconditional selection of the "malloc allocator"
should be so greatly influenced by the presence of or lack thereof
pthread_* symbols (which should be the only difference on this platform).

I will post a full updated analysis once I have gained more data from
daily runs on multiple FreeBSD CPU archs.  Also, once I contribute
back a change that will make it easier for others to test the various
configurations on their platform, we should have data for other malloc
implementations in presence of that one change.

Regards,
Loren