Allocator performance testing

[Stefan Olsson]

Hi!

Measuring performance and comparing different solutions/approaches is as 
always tricky. However we felt that we needed some _simple_ tools to 
make sure that the allocator (aimed at MT applications) that we are 
working on performs as expected.

The two attached files contains our current approach to comparing 
performance relative to the current __pool_alloc allocator. The main 
reason for this post is to get much needed input on other cases that 
must be tested and/or other - maybe already existing - tools that we are 
not aware of.

Below are some figures from two different machines (single/dual, both 
running Linux 2.4.18). The overall conclusion is that the current 
__pool_alloc generates an awful amount of context switching (as expected 
due to the single global lock) and thus performs worse and worse with an 
increased number of threads and that the Linux malloc() implementation 
actually performs - relatively speaking - better and better the more 
threads (as do our proposed allocator :)

Specifics as to the number of threads, approach etc - have a look at the 
code :)

NOTE! The numbers from the alloc_perf_comp_mt.cc version includes 
figures from testing a crude version of our allocator which will result 
in a patch for review soon - so far it's looking good and there are 
quite a few things in there addressing other issues that this simple 
test can't reveal (in terms of long term fragmentation, heap growth etc).

For your reference - this is the compiler used:
Reading specs from 
/root/projects/alloc/local/lib/gcc-lib/i686-pc-linux-gnu/3.4/specs
Configured with: ../gcc/configure --prefix=/root/projects/alloc/local 
--enable-threads
Thread model: posix
gcc version 3.4 20030202 (experimental)

g++ alloc_perf_comp_single.cc -O2 -static

On single 1GHz PIII laptop:
Target run-time: 10s
Calibrating test_ints... DONE! Will do 5400000 iterations.
__pool_alloc... DONE! Time 9.888797
__malloc_alloc... DONE! Time 14.835390
Relative performance to __pool_alloc:
__malloc_alloc 66.656805 %

On dual 1GHz PIII server:
Target run-time: 10s
Calibrating test_ints... DONE! Will do 5500000 iterations.
__pool_alloc... DONE! Time 10.030389
__malloc_alloc... DONE! Time 15.172492
Relative performance to __pool_alloc:
__malloc_alloc 66.109041 %

g++ alloc_perf_comp_mt.cc -O2 -static -pthread

On single 1GHz PIII laptop:
Target run-time: 10s
Calibrating test_ints... DONE! Will do 2700000 iterations.
__pool_alloc... DONE! Time 115.985574
__malloc_alloc... DONE! Time 97.495789
__mt_alloc... DONE! Time 55.502588
Relative performance to __pool_alloc:
__malloc_alloc 118.964701 %
__mt_alloc 208.973272 %

On dual 1GHz PIII server:
Target run-time: 10s
Calibrating test_ints... DONE! Will do 2700000 iterations.
__pool_alloc... DONE! Time 86.065636
__malloc_alloc... DONE! Time 97.874511
__mt_alloc... DONE! Time 55.050467
Relative performance to __pool_alloc:
__malloc_alloc 87.934678 %
__mt_alloc 156.339520 %

Brgds

/Stefan

-- 
Always yield to temptation-because it may not pass your way again.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alloc_perf_comp_single.cc
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030205/1c936963/attachment.cc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alloc_perf_comp_mt.cc
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030205/1c936963/attachment-0001.cc>