Re: Optimized compilation
On Fri, Oct 11, 2002 at 08:12:54PM -0700, David Schleef wrote:
> On Sat, Oct 12, 2002 at 08:20:13AM +1000, Glenn McGrath wrote:
> > It really grates on my nerves to hear people arguing that it only makes
> > it a little bit faster so its not worth doing.... its shouldnt be your
> > decision, let the user decide if they want to take full advatage of their
> > hardware, or run it in 1985 emulation mode.
> In case you hadn't noticed, most modern CPUs will execute even
> really crappy assembly code optimally. Most instruction-level
> bottlenecks come from data dependencies, which is a direct
> result of the way the C code is written. This is not something
> that the compiler can optimize around without breaking the C
> standard.
> CPU manufacturers have made compiler-based optimizations largely
> irrelevant. A better approach to doing something really
> meaningful is to find poorly performing inner loops and rewrite
> them with an eye on improving instruction flow through modern
> CPUs.
This isn't true of the Sparc (it is pipelined rather than out of
order, deeply pipelined in the case of the UltraSparcIII). ia64 is a
VLIW processor, which makes its performance extremely dependent on
compiler optimizations. Dunno where the rest of our archs stand.
Actually, Debian performance on the sparc is _really_ bad because of
backwards compatibility. gcc, by default, targets a sparc chip that
doesn't have integer multiply. (BenC says this will change after the
gcc3.2 transistion.)
(Although, I think gentoo goes to the other extreme and compiles
everything as 64-bit code on newer sparcs, which can give a 2x
performance hit in some cases.)
But I agree that it's not worth it to have multiple sub archs for the
entire x86 distribution. (However, it could be argued that some code,
like mpeg decoders, be distributed for multiple subarchs.)
Steve
dunham@cse.msu.edu
Reply to: