🚀 go-pugleaf

From article <1991Dec30.012934.10270@afterlife.ncsc.mil>, by sjr@afterlife.ncsc.mil (Stephen J. Roznowski):
> I was going some timings of the fcrypt routines that are a part of Crack,
>
> On a Sun4-75, cc -O3 was about 17% faster than gcc.
>
> Does anyone care to explain why the Sun compilers seem to generate faster
> code?

I obtained the following figures on an SS2:

GCC 1.39:    gcc -O -static     567 fcrypt/s  ( 85%)
Bundled CC:  cc -O4 -Bstatic    666 fcrypt/s  (100%)

[SPARCstation 2, 64M RAM, SunOS 4.1.1B, crack-4.0b, running "speedfcrypt"]

Believe it or not on this benchmark GCC 1.39 actually executes fewer
instruction than Bundled CC.  However it incurs a very large number of
load use stalls (17% of all machine cycles).  On current SPARC chips
the result of a load instruction is not available for use until after
one cycle following the completion of the load.  Thus an important
aspect of generating good code is to rearrange the instructions to
minimize such pipeline stalls.  This is not currently performed.

Normally it would not be fair to post the rest of this message, but
since a beta release of GCC 2 is likely to be available fairly soon it
becomes less unreasonable.  You should view it however as being mainly
a discussion about the internal performance details of GCC, and not
compare the figures with those of Sun's current compilers.

You will be pleased to hear that GCC 2 performs instruction
scheduling.  The latest version of GCC 2 under development provides
the following performance figures

GCC (Dec. 24th):  gcc -O5 -static   737 fcrypt/s  (111%)

About half the increase in performance over GCC 1.39 for this
benchmark came from instruction scheduling, while the other half came
from generating better, that is fewer instructions.  Note however that
these results do not come from a stable compiler, so the results must
be interpreted with caution.  For instance with a slightly earlier
version I get the following figures

GCC (Nov. 25th):  gcc -O5 -static   798 fcrypt/s  (120%)

The latest version generates poorer code because it no longer stores a
particular loop index variable in a register.  This could be an
unintended side effect of some other change, but it could also be the
case that the optimization it was previously performing can not be
guaranteed safe, and thus has had to be disabled.  The possibility of
other similar problems being discovered in other aspects of the
compiler means that you must interpret these performance figures with
considerable caution.  GCC 2 is after all currently vapourware.

It would not be fair for instance to compare these figures with those
of Sun's current compilers to determine which compiler is better.
Sun's current compilers are probably slightly better than GCC at
present.  And until GCC 2 is released Sun should be given the benefit
of the assumption that they are likewise making use of their time by
improving both their unbundled and bundled compilers.  Whatever the
puported truth on the latter may be.

                                         Gordon Irlam.
                                         (gordoni@cs.adelaide.edu.au)