On Wed, 3 Jul 2002, Garance A Drosihn wrote:

> At 11:01 PM -0700 7/2/02, Matthew Dillon wrote:
> >     I get just about the same performance for GCC2 as I
> >     do for GCC3 in the tests I've run so far.  It makes
> >     me wonder what the hell GCC3 is burning all that
> >     cpu *on*.
> One of the guys here at RPI (dec, actually) claims he got
> buildworld under current to run at more reasonable speeds
> by explicitly setting the CPUTYPE.  I haven't had the time
> to run any experiments with that yet.

I got some improvements in generated code for a microbenchmark by
compiling with -march=<runtime arch>.  gcc on i386's now likes to
"optimize" "andb $1,%al" and "testb $1,%al" as "andl $1,%eax" and
"testl $1,%eax", respectively.  This tends to give a large pessimization
(50% for the above in a loop) on at least PentiumPro's and PII's due
to a partal register stall.  Compiling with -march=pentium2 regains
the original speed on a Celeron400 at least by zero-extending %eax
before using it, but double-crosses itself by going back to using
%al and not actually using %eax.  Manually changing the code back
to use %eax gave a 5% speedup for the loop relative to the old
version.  The manual change also gave a 5% speedup for an AthlonXP.
AthlonXP's don't have partial register stalls and all versions
generated by gcc gave the same results (-march=athlon-xp generated the
same code as -march=pentium2).

Summary: we can break even on all tested arches with gcc-3 for the
microbenchmark by setting CPUTYPE right.  We can beat gcc-2 by tweaking
the generated code to be what gcc-3 apparently intended.

But I don't like setting CPUTYPE or use -march, since I want to run
the same code on different (i386-sub-)arches.  I have 2 different ones
on active machines and 3 more on inactive machines).  Releases need
to run on even more arches.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to