This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gzip performance test
- To: jfm2 at club-internet dot fr
- Subject: Re: gzip performance test
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Fri, 25 May 2001 10:58:50 -0400
- cc: Joe Buck <jbuck at synopsys dot COM>, gcc at gcc dot gnu dot org
I do not think that gzip is a very useful performance test. It
mainly is a question of how well GCC optimizes one loop. The gzip part of
the GCC 3.0 release criteria was more about code quality and not
encoutering a regression, not about showing a large improvement.
Using nbench / BYTEmark benchmark for powerpc-ibm-aix4.3.3.0
GCC 2.95.3 gets:
MEMORY INDEX : 1.699
INTEGER INDEX : 2.205
FLOATING-POINT INDEX: 3.583
GCC 3.0 prerelease gets:
MEMORY INDEX : 1.748
INTEGER INDEX : 2.683
FLOATING-POINT INDEX: 3.710
IBM's XLC 3.6.6 gets:
MEMORY INDEX : 1.830
INTEGER INDEX : 2.294
FLOATING-POINT INDEX: 3.960
All of this is un-scientific and not official results of any
kind. By this comparison, gcc-3.0 looks pretty good at the basic C
optimization level.
As usual, the real advice is use the compiler to test an
application that is representative of the type of work on which it will be
used.
I know that a lot of people use gzip, but it is not a very broad
test. gzip-1.2.4a does not show any regression on powerpc-ibm-aix4.3.3.0,
so I think it passes the code quality test. I do not think that the x86
and PowerPC machine description improvements are stressed by gzip.
David