This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Allocator performance numbers for sparc-sun-solaris2.8
Previously I submitted some test results that exercise the mt
allocator with and without GLIBCXX_FORCE_NEW on sparc-sun-solaris2.8.
Paolo mentioned that numbers for the pool allocator would also be
useful for this target, so here they are, albeit with the (recent)
trunk instead of gcc-3.4.0 + rev 1.28 of mt_allocator.h.
For reference those previous results first:
gcc-3.4.0 + single-thraded + mt-1.28 + GLIBCXX_FORCE_NEW:
Number of slots
Size 1 8 64 1024 8192 1048576
---- ------- ------- ------- ------- ------- -------
8 bytes 0.86418 0.89329 0.84365 0.90939 0.89484 0.94090
128 bytes 0.87358 0.93001 0.94089 0.93079 0.97717 0.96576
1024 bytes 1.13391 1.03313 1.02558 1.09105 1.11196 1.19894
gcc-3.4.0 + single-threaded + mt-1.28:
Number of slots
Size 1 8 64 1024 8192 1048576
---- ------- ------- ------- ------- ------- -------
8 bytes 4.27259 2.40072 2.47618 2.51368 2.28899 2.33543
128 bytes 4.07367 2.99436 2.8585 3.06182 2.73997 2.29598
1024 bytes 1.06566 0.99703 0.99104 1.06024 1.17302 1.19914
With the new tests below, I am using pool_allocator.h rev 1.11 from trunk gcc:
Configured with: ../../gcc-3.5.0/configure --with-dwarf2
--enable-languages=c,c++ --enable-threads=single --disable-shared
--prefix=/hosts/bubbles/spencer/devel/gcc/install/gcc-3.5.0-cross/sparc-sun-solaris2.8
--with-gnu-as --with-gnu-ld --disable-multilib --enable-concept-checks
--enable-clocale=generic --enable-libstdcxx-allocator=pool
--target=sparc-sun-solaris2.8
--with-headers=/hosts/bubbles/spencer/devel/gcc/gcc-3.5.0/sparc-sun-solaris2.8/target-stuff/include/
--with-lib=/hosts/bubbles/spencer/devel/gcc/install/gcc-3.5.0-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/lib
Thread model: posix
gcc version 3.5.0 20040510 (experimental)
Note that even though I did --enable-threads=single, I got thread
model "posix". I'm not sure how that happened but I worry it may have
influenced the numbers. I will try to fix this and repeat these tests
when I have some free moments. Sorry for this extra variable.
The numbers in the table are the number of times faster the
pool_allocator-based operator new() is relative to the default operator
new() on a sparc-sun-solaris2.8 Sun Netra-T1 (a relatively slow box).
With GLIBCXX_FORCE_NEW set, using the pool allocator:
gcc-3.5.0 + posix + pool-1.11 + GLIBCXX_FORCE_NEW:
Number of slots
Size 1 8 64 1024 8192 1048576
---- ------- ------- ------- ------- ------- -------
8 bytes 0.93359 0.94446 0.96684 0.93678 0.92446 0.86745
128 bytes 0.93389 0.93910 0.93030 0.95281 0.98772 0.99589
1024 bytes 1.0637 1.05257 1.1844 1.01189 1.09382 1.19996
These are basically the same as for the mt allocator, as expected.
gcc-3.5.0 + posix + pool-1.11:
Number of slots
Size 1 8 64 1024 8192 1048576
---- ------- ------- ------- ------- ------- -------
8 bytes 1.19885 1.4469 1.42348 1.49423 1.47735 1.57163
128 bytes 1.21163 1.58352 1.61743 1.63135 1.57391 1.8448
1024 bytes 1.05288 1.05426 1.04563 1.04733 1.13336 1.19336
These numbers are not as impressive as the values using the
mt_allocator. I ran the same test with my gcc-3.3.2 (that I use for
production builds):
gcc-3.3.2 + single-threaded + pool from that release:
Number of slots
Size 1 8 64 1024 8192 1048576
---- ------- ------- ------- ------- ------- -------
8 bytes 3.80291 2.36915 2.41673 2.42373 2.24539 2.61188
128 bytes 3.72304 2.65005 2.79785 2.67388 2.89386 2.40624
1024 bytes 1.19522 1.14851 1.11493 1.14219 1.19909 1.32487
So the 3.5 mt allocator (in 3.4) seems to beat the 3.3 pool allocator
and the 3.5 pool allocator for this target.
--
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company