This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: performance testresults


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]