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 <20030624130604.767129a9.bkoz@nabi.net>,
"B. Kosnik" <bkoz@nabi.net> writes:

>> Run without -pthread:
>> 
>> allocator.cc             	default   	1241r 1234u    0s    0pf 
>> allocator.cc             	malloc    	2433r 2163u    2s    0pf 
>> allocator.cc             	mt        	1389r 1303u    0s    0pf 

>> Run with -pthread (by manually hacking libstdc++-v3/scripts/check_performance):
>> 
>> allocator.cc             	default   	1190r 1141u    0s    0pf 
>> allocator.cc             	malloc    	 426r  399u    1s    0pf 
>> allocator.cc             	mt        	 480r  468u    0s    0pf 

> About what I am seeing on linux. 

> I don't know how to proceed on sorting out the default allocator issue.
> I like the suggestion here about switching over to mt_alloc if pthreads:

> http://gcc.gnu.org/ml/libstdc++/2003-06/msg00119.html

> That seems easiest to do, considering the alternatives.

Yikes!!!!  To Carlo: It is the issue I suspected.  However, please
note that we may not compare runs without -pthread against runs with
-pthread since allocator.cc (at least) uses a non-deterministic
pre-scaling routine.  Humm...  We may only observe that relatively
speaking, the situation flips when mutex overhead is introduced.  We
shouldn't even compare that test one day to the next given its design.

>> (BTW, yes, I think we should run the test cases with and without
>> e.g. -pthread esp. if we find it matters even for non-threaded cases.
>> I'll make it possible to run either way without having to change a
>> srcdir file perhaps by respecting the same RUNTESTFLAG format that
>> dejagnu honors.)

> Sounds like a good idea.

OK, I will wack that out when time allows.