🚀 go-pugleaf

In article <1196@s8.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> In article <1797@apctrc.UUCP>, zrra07@backus (Randall R. Appleton) writes:
> > I have a simple question:  Does anyone know what sort of speed-up
> > on gets by going from a good implementation of some algorithm in a
> > third generation language (C, Fortran) and a good optimizing compiler
> > to hand-coded assembly?
> > 
> > In other words, if I take my average well written program, compiled
> > with a good optimizing compiler, and re-write it in assembler, what sort
> > of speedup should I expect to see?
> 
> On many machines, like the CDC 6600 and the R/6000, the FORTRAN compilers
> are going to get as much or more than you are. You will normally
> produce very slow code on a 6600 unless you really understand the
> scheduling of the functional units. The FORTRAN compiler for the
> R/6000 produces such good code that IBM has decided to implement
> ESSL (a major assembly code on the 3090) in FORTRAN on the R/6000.
> Their reason is that they can't beat the FORTRAN code.

In the far distant future, there may be languages in which algorithms as
I can express them NOW can be reasonably coded.  I happen to be familiar
with the scheduling of the functional units on the 6600, and would very
definitely change my algorithms to take advantage of that.  It is quite
likely that the HLLs do not have the capabilities of recognizing the
modified algorithms.

The programmer who is not given that scheduling information cannot produce
near-optimal code.  The compiler is not going to be able to revise the
algorithm other than trivially.  An intelligent human with an optimizing
_assembler_ which provides feedback will do the best.

> There are machines like the i860 where hand coded assembler is a lot
> faster than most compiled code, but if people still have i860 compilers
> ten years from now, you should expect the compiler code to be faster
> than hand generated, since the i860 is so complicated. Once you figure
> out how to take advantage of the weird hardware, the compiler _always_
> takes advantage. The assembler language programmer is not as
> consistent.

The compiler cannot take advantage of the weird hardware to change the
algorithm.  The best practical solution is to enable the programmer to
provide some method of trying out many (maybe even thousands or millions)
algorithmic versions and seeing which turn out better.  There probably 
should be interactions between the processor and the programmer as to
whether certain modifications can be made.  But these are things the
compiler alone cannot do.


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)