🚀 go-pugleaf

>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)