egcs 1.0 *faster* than Sun's C compiler!!!!

egcs 1.0 *faster* than Sun's C compiler!!!!

[Harvey J. Stein]

Thought you guys might like to see this:

Sun, compiled with gcc -O3 -funroll-loops -finline-functions -ffast-math -fomit-frame-pointer -msupersparc
   28.88user 0.27system 0:29.26elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (0major+0minor)pagefaults 0swaps

Sun, compiled with cc -fast -xO4 -xdepend -xchip=ultra -xarch=v8plusa
   39.86user 0.21system 0:40.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (0major+0minor)pagefaults 0swaps

Sun, compiled with cc -fast -xO5 -xdepend -xchip=ultra -xarch=v8plusa
   39.70user 0.17system 0:39.95elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (0major+0minor)pagefaults 0swaps

Alpha, compiled with gcc -O2
   11.82user 0.15system 0:12.08elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (278major+1690minor)pagefaults 0swaps

The sun is a 200mhz ultra-sparc.
The alpha is a 533mhz alpha.

Expect the sun numbers to go down by 1/3 on a 300mhz ultra-sparc.

Gcc on the sun is egcs 1.0.  Gcc on the alpha is gcc 2.7.2.1.

Is it typical that gcc optimizes *better* than Sun's C compiler?

-- 
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Joe Buck]

> Thought you guys might like to see this:

[ times for unspecified example deleted ]

> Is it typical that gcc optimizes *better* than Sun's C compiler?

In the past, my experience has been that gcc is sometimes faster,
sometimes slower than Sun's compiler, and that at least for 2.7.2.x,
I'd say Sun's was slightly better on average (though it's not hard
to write programs where gcc does better).

Before saying anything definite, we need to have done a rigorous
benchmarking study or the compiler community will simply laugh at us.

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Marcus Thiessel]

>>>>> "Harvey" == Harvey J Stein <hjstein@bfr.co.il> writes:


    Harvey> Sun, compiled with gcc -O3 -funroll-loops
    Harvey> -finline-functions -ffast-math -fomit-frame-pointer
    Harvey> -msupersparc 28.88user 0.27system 0:29.26elapsed 99%CPU

    Harvey> Sun, compiled with cc -fast -xO4 -xdepend -xchip=ultra
    Harvey> -xarch=v8plusa 39.86user 0.21system 0:40.15elapsed 99%CPU

    Harvey> Sun, compiled with cc -fast -xO5 -xdepend -xchip=ultra
    Harvey> -xarch=v8plusa 39.70user 0.17system 0:39.95elapsed 99%CPU

    Harvey> Alpha, compiled with gcc -O2 11.82user 0.15system
    Harvey> 0:12.08elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

    Harvey> The sun is a 200mhz ultra-sparc.  The alpha is a 533mhz
    Harvey> alpha.


    Harvey> Is it typical that gcc optimizes *better* than Sun's C
    Harvey> compiler?

Well, SUNPro should be faster since you've pay for it. A major point
to argue about are the options to use. For example I don't what
-ffast-math does but what about enabling a simliar feature when
running SUNPro!? And why limit the instruction set to -xarch=v8plusa!?

My choice when running those tests is to iterate on set of options for
a certain compiler (and machine) in order to get the fastest run. This 
is rather time consuming and the results merly depend on the fact how
much you know aboutn the compiler.

--Marcus

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Richard Henderson]

On Wed, Dec 17, 1997 at 05:46:29PM +0100, Marcus Thiessel wrote:
> Well, SUNPro should be faster since you've pay for it. A major point
> to argue about are the options to use. For example I don't what
> -ffast-math does but what about enabling a simliar feature when
> running SUNPro!?

Indeed.  I believe the option is -fast.

> And why limit the instruction set to -xarch=v8plusa!?

v8plusa is all of the v9 instructions except the full 64-bit
register instructions, which you can't use on Solaris.


r~

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Harvey J. Stein]

Joe Buck <jbuck@synopsys.com> writes:

> > Thought you guys might like to see this:
> 
> [ times for unspecified example deleted ]
> 
> > Is it typical that gcc optimizes *better* than Sun's C compiler?
> 
> In the past, my experience has been that gcc is sometimes faster,
> sometimes slower than Sun's compiler, and that at least for 2.7.2.x,
> I'd say Sun's was slightly better on average (though it's not hard
> to write programs where gcc does better).
> 
> Before saying anything definite, we need to have done a rigorous
> benchmarking study or the compiler community will simply laugh at us.

There's no such thing as a rigorous benchmarking study.  The variety
of applications is too varied.  The only thing that's truly of value
is testing the app you're interested in.  In this particular case, the
particular application I'm interested in runs 30% slower when compiled
with Sun's C compiler.

-- 
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Harvey J. Stein]

Marcus Thiessel <thiessel@itwm.uni-kl.de> writes:

> 
> >>>>> "Harvey" == Harvey J Stein <hjstein@bfr.co.il> writes:
> 
>     Harvey> Is it typical that gcc optimizes *better* than Sun's C
>     Harvey> compiler?
> 
> Well, SUNPro should be faster since you've pay for it.

I didn't notice any smiley there.  If that's your belief, why are you
even reading the egcs mailing list?  Although in my lifetime I've
often noticed a loose correlation between price and value, I've also
noticed that it's only a correlation - not a physical law.

> A major point
> to argue about are the options to use. For example I don't what
> -ffast-math does but what about enabling a simliar feature when
> running SUNPro!? And why limit the instruction set to -xarch=v8plusa!?

Then maybe you'd like to look at the man pages in question.  I'm not
"limiting the instruction set".  I'm telling the compiler to use all
features available on the v8plusa, and not to try to produce a binary
that'll run a larger family of CPUs.  Since the machine in question is
a v8plusa, this produces better code.  RTFM.  In any case, these are
the options that *Sun* told me to use.  Good enough for you?

> My choice when running those tests is to iterate on set of options for
> a certain compiler (and machine) in order to get the fastest run. This 
> is rather time consuming and the results merly depend on the fact how
> much you know aboutn the compiler.

Time consuming isn't the word for it.  With 20 switches that can
be set independently, you'd be talking about 1,048,576 tests.  At 40
seconds a run (and 10 minutes to build the application), that'd take
about 13 years, at which point faster hardware and better compilers
would be available.  Hopeless is more the word for it.

So yes, we come to a point where we agree.  The more you know about
your compiler, the better the chances of you using it effectively to
produce fast code.

-- 
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il

Re: egcs 1.0 *faster* than Sun's C compiler!!!!

[Marcus Thiessel]

>>>>> "Harvey" == Harvey J Stein <hjstein@bfr.co.il> writes:

    Harvey> Marcus Thiessel <thiessel@itwm.uni-kl.de> writes:
    >> 
    >> Well, SUNPro should be faster since you've pay for it.

    Harvey> I didn't notice any smiley there.  If that's your belief,
    Harvey> why are you even reading the egcs mailing list?  Although
    Harvey> in my lifetime I've often noticed a loose correlation
    Harvey> between price and value, I've also noticed that it's only
    Harvey> a correlation - not a physical law.

Well, maybe the smiley got lost here! :-) But indeed (I wish to)
believe commercial compilers should produce faster code! I know this
is not always true ...

    Harvey> Then maybe you'd like to look at the man pages in
    Harvey> question.  I'm not "limiting the instruction set".  I'm
    Harvey> telling the compiler to use all features available on the
    Harvey> v8plusa, and not to try to produce a binary that'll run a
    Harvey> larger family of CPUs.  Since the machine in question is a
    Harvey> v8plusa, this produces better code.  RTFM.  In any case,
    Harvey> these are the options that *Sun* told me to use.  Good
    Harvey> enough for you?

Good for me? I did recognize you did that for me? :-) BTW, have you
ever tried SPEC97 switches!?


    Harvey> Time consuming isn't the word for it.  With 20 switches
    Harvey> that can be set independently, you'd be talking about
    Harvey> 1,048,576 tests.  At 40 seconds a run (and 10 minutes to
    Harvey> build the application), that'd take about 13 years, at
    Harvey> which point faster hardware and better compilers would be
    Harvey> available.  Hopeless is more the word for it.

Some of these switches are of type mutex and some don't make sense. So 
it is not neccessary to iterate over the complete set. :-)

--Marcus