This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CVS performance regression over 2.7.2 on SPECint95 on sparc
On Fri, 01 Dec 2000, Dan Nicolaescu wrote:
> % increase % increase
> execution execution
> for gcc-CVS for gcc-2.7.2.3 for gcc-2.95.2 time time
> Base Base Base Base Base Base Base gcc-CVS vs gcc-2.95.2 vs
> Benchmarks Ref Time Run Time Ratio Run Time Ratio Run Time Ratio gcc-2.7.2.3 gcc-2.7.2.3
> ------------ -------- -------- -------- -------- -------- -------- -------- ---------- -----------
> 099.go 4600 449 10.2 394 11.7 435 10.6 13.95% 10.40%
> 124.m88ksim 1900 234 8.12 244 7.80 289 6.58 -4.09% 18.44%
> 129.compress 1800 352 5.11 224 8.05 260 6.93 57.14% 16.07%
> 130.li 1900 254 7.48 256 7.42 264 7.21 -0.78% 3.12%
> 132.ijpeg 2400 252 9.53 246 9.77 266 9.04 2.43% 8.13%
> 134.perl 1900 207 9.17 202 9.40 193 9.83 2.47% -4.45%
> 147.vortex 2700 2.40 --X 323 8.36 314 8.61 N/A -2.78%
>
go, m88ksim and compress are the real bad ones. Some benchmarks
are more stable than others. For instance, li and compress
fluctuate as much as +/-6% from one day to the next. While gcc
and perl are typically in the +/-1% range.
> > Bear in mind that you're comparing to a really ancient version of
> > gcc.
>
> Isn't that an agravating factor?
>
Yes, but not suprising given the lack of performance monitoring.
> One obvious place where gcc is at disadvantage compared to other
> compilers is compress, it has a function to read bytes from the
> buffer to be compressed that just does:
>
OK, but you have to remember that GCC is weak in key pieces
of infrastructure that heavy-duty optimizing compilers tend to
use. Things like IPA, loop transformations, global register
allocation, cache transformations, etc.
Work on these large pieces of infrastructure takes time but
usually give you much better results than micro changes.