EGCS performance ?

[N8TM@aol.com]

In a message dated 10/30/98 3:24:49 PM Pacific Standard Time,
ruoccos@comm2000.it writes:

> If someone could test with a better benchmark EGCS vs. other
>  compilers on different (RISC) architectures we could determine this
>  performance gap still exists, and how much is due to x86 scheduling
>  arcana (if they come on par) vs to machine-independent optimizations
I would expect widely varying interests on this list, as to what constitutes
an interesting or relevant benchmark.  I've run Livermore Kernel tests of
several compilers on several architectures, and egcs does a satisfactory job
on x86 at -Os.  However, one of my application codes runs 50% faster with lf90
than with egcs, so LFK doesn't even cover the possibilities for engineering
floating point intensive analyses. egcs with the Pacific-Sierra f90 translator
beats all the commercial compilers on the infamous Dave Frank matrix
inversion, and also wins in the C version.

 To go to the other extreme, egcs varies from 20% faster to 100% slower than
HPUX Fortran on LFK's on an hppa1.1 machine, which shows egcs in a better
light than the current hppa2 machines. 

The greatest problems with egcs on x86 are the excessive register spill
situations, where optimizations which work on RISC architectures with a
reasonable number of registers are bad on x86.  I've seen hints that
improvements are in the works in the ability of egcs to deal with spills.
That's machine dependent mainly in the dependence on the number of
independently programmable registers.  Forgive my ignorant over-
simplification.

 I've taken the liberty of modifying some of the LFK kernels so they don't
depend on compilers recognizing specific oddly coded loops or optimizing
obsolete syntax.  This helps the commercial compilers as much as it does egcs,
but makes the results more meaningful as a test of performance on reasonable
source code.