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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
