Gnu C vs. cc

[Joe Buck]

In article <1990Oct31.235041.21555 at rice.edu>, wsrcc!wolfgang at uunet.uu.net (Wolfgang S. Rupprecht) writes:
> >On the Sun/3 gcc makes a significant improvement (3 times faster in
> >places) to the X server, but hardly makes any difference for Sparc or 386i
> >architectures.

> Well, the truth is on a SPARC (SLC if it matters) gcc 1.37.1 is sometimes
> even worse than cc.  The infamous drystone string copy test runs about
> 19,000 drysstones with 'cc -O' and only 14,000 with 'gcc -O'.  Setting the
> more esoteric gcc flags singly or in groups has little effect.

The main reason for gcc's worse performance on Sparc is that it doesn't do
instruction scheduling or delayed branches.  However, Mike Tiemann (author
of g++) has an instruction scheduler that will be included in the 2.0
version of gcc/g++ that does these things; he claimed a 30% performance
improvement for Sparc last April when he talked at the Usenix C++
Conference.  Needless to say, I am eagerly awaiting this compiler, which
will also integrate NeXT's Objective-C compiler so that the same program
will compile C, C++, and Objective-C.

On the other hand, dhrystone is a bogus benchmark; it doesn't mean
anything because it doesn't produce output that depends on input.  A very
smart compiler, detecting that certain loops don't do anything, will throw
away whole functions.  So the dhrystone people tell you to run your
compiler with some types of optimization turned off!

Stupid.  People who write toy benchmarks like this call standard compiler
optimizations "cheating" and figure out how to insert code that defeats
optimizers, even though such code has nothing to do with what people
really do with computers.  Vendors end up putting little tricks in their
compiler to make Dhrystone, Whetstone, etc, run fast at the expense of
other code.

Pay attention to real benchmarks, like SPEC, which measures how fast real
applications run.

Joe Buck
jbuck at galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck