ram+@cs.cmu.edu (Rob MacLachlan) (04/26/91)
>Subject: Re: SPARC implementation or architecture >Date: 23 Apr 91 14:01:40 GMT > >|> However, the major conclusion: that the two are indistinguishable, >|> is wrong, if you think 10% is distinguishable... >|> -- >|> -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> >The last sentence is the point! MIPS marketing (at least as retold >by DEC) is that the MIPS compiler technology provides a *HUGE* >advantage over other RISC architectures. If the difference is >+/- 10%, that is a whole different story. My experience in writing an optimizing Lisp compiler has lead me to believe that for existing non-scientific code, compiler technology can't make a huge difference. The most important thing is to have reasonable global register allocation. Everything else is 10% or less (though all combined can add up to as much as 30%). This is especially true in pointer-chasing code. Much of the vaunted flow optimizations (strength reduction, global common subexpression, loop invariant) are profitable mainly in code that makes intensive use of multi-dimensional arrays. These optimizations can make all programming easier, but especially in C, it is usually easy (and common practice) to hand-optimize your code so that there are no loop invariants, common subexpressions or spurious multiplications. The reason I made the remark about "existing code" is that existing code is usually written to assume the lowest common denominator in compilers. In more than one sense, it is easy to write code that assumes a smart compiler: -- Programs that are not highly tuned may do dumb things which a smart compiler can undo. Even experienced programmers with a knowledge of compilation technology can write code that may compile badly (especially in a complex language like Lisp.) -- If you are willing to assume good compiler technology (such as appropriate inlining of small and once-called functions), then programs are easier to write and maintain, since you don't have to be paranoid about efficiency. Robert MacLachlan (ram+@cs.cmu.edu)