This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: performance testresults
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: stefan at xapa dot se
- Date: Wed, 4 Feb 2004 17:35:11 -0600 (CST)
- Subject: Re: performance testresults
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <20040204003552.28e938ab.bkoz@redhat.com>
> this looks a bit strange to me since it doesn't match my testresults
> (outside of the libstdc++ testsuite). I know, I should find the answer
> to this myself but I have not access to the machine where I have the
> required tools (tcl etc) right now...
Guys, I took a look at Benjamin's numbers. It looks like some of the
tests are swapping (is that possible, Benjamin?): 'r' time way higher
than 'u'+'s'. For this reason, I personally think that 'r' time is
useless other than as an indirect measure that (e.g. in this case)
__mt_alloc may be taking more memory to run the same work-load.
> ...are the single threaded tests compiled with -pthread or not? When
> compiled with -pthread on a single threaded application mt allocator is
> about 10-20% slower than raw malloc in this kind of test.
They are done both ways now. Note:
allocator.cc [...]
[...]
allocator.cc-pthread [...]
> Also, if one modifies the test to call do_loop(obj); twice the results
> are quite different...
> ...at least on Linux where I have done the tests/development. This is
> due to the fact that the second time, free memory is "found" much faster
> by mt allocator than by malloc.
Yes, it might be interesting to report a second run with a hot cache
since that too mirrors real-world cases.
BTW, Benjamin, I'm a little confused on some of the messages I got
CC'd on. Did you want me to change something else in the test cases?
Regards,
Loren