public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: N8TM@aol.com
To: ruoccos@comm2000.it, egcs@cygnus.com
Subject: Re: EGCS performance ?
Date: Fri, 30 Oct 1998 19:14:00 -0000	[thread overview]
Message-ID: <e9012605.363a8066@aol.com> (raw)

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.

             reply	other threads:[~1998-10-30 19:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-30 19:14 N8TM [this message]
1998-10-31 16:39 ` Joe Buck
  -- strict thread matches above, loose matches on Subject: below --
1998-10-29  0:50 Ben Cheese Was: Bernd's reload patch installed Robert Lipe
1998-10-30  5:07 ` EGCS performance ? Sergio Ruocco
1998-10-30 15:21   ` David Edelsohn
1998-10-31 16:39     ` Joe Buck
1998-10-30 15:21   ` Joe Buck
1998-10-30 19:14   ` Robert Lipe
1998-10-31  5:02   ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9012605.363a8066@aol.com \
    --to=n8tm@aol.com \
    --cc=egcs@cygnus.com \
    --cc=ruoccos@comm2000.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).