sebor@roguewave.com (Martin Sebor) writes:
An interesting datapoint for libstdc++ folks might be that
the gcc 3.2 C++ Standard iostream implementation is nearly
three times slower than the next slowest implementation on
SunOS (SunPro 5.3's libstd 2.1.1) and 5 times slower than
the fastest tested implementation on SunOS (SunPro 5.3
with STLport 4.5).
I don't doubt your observed numbers for gcc 3.2 on SPARC; however,
someone will have to debug why this is so if I guess wrong below.
First a baseline of what I see: With gcc 3.3 (experimental) circa
20021003, for the code exactly as you posted it, I see the following
on sparc-sun-solaris2.7 (note: this is really old hardware):
; /usr/local/beta-gcc/bin/g++ -O3 -R/usr/local/beta-gcc/lib t.C
; time a.out >/dev/null 1000000
11r 10.6u 0.1s a.out 1000000
; time a.out >/dev/null 1000000 stdio
11r 10.8u 0.1s a.out 1000000 stdio
I see the same performance profile with current mainline and 3.2.X
code (although somewhat beyond the 3.2 release) on i386-*-freebsd4.
Looking though the ChangeLog delta between 3.2 release and tip of
3.2.X, I know of no library code change that should affect this issue
after 3.2 release *as* *long* *as* the library that you are testing
was installed via a full bootstrap process. I would ask that you
ensure that you are actually linking against the 3.2 version of the
libstdc++-v3 library as is built during a full 3.2 bootstrap cycle.
If you build libstdc++-v3 outside a full compiler bootstrap, then you
don't get the same optimization by default (this was true circa 3.2
release but was perhaps recently changed).
Martin, could you confirm that you indeed tested the libstdc++-v3
library as was built during a normal gcc bootstrap process?
Yes, I used a stock installation of gcc 3.2 and libstdc++. I can