Languages vs. machines (was Re: The need for D-scussion)

[Herman Rubin]

In article <10808 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> >>In article <719 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:

    ......

> >In article <10763 at mimsy.UUCP> I answered with
 
......

> In article <5308 at hall.cray.com> pmk at hall.cray.com (Peter Klausler) writes:

.......
> 
> >... What I'm getting at with all this rambling is this: Knowing your target
> >architecture is a GOOD THING if you're after optimal performance.  Knowing
> >your processor's assembly language - and how to optimize it - will make you
> >a better user of your "high-level" language (FORTRAN, C, etc.).  It will also
> >frustrate you, as it has me, and as I fear it has frustrated Herman.
> 
> Sure.  But maybe you can make it `good enough' without sacrificing
> portability; or perhaps you will have to throw portability to the
> wind---but maybe not entirely!  .......

> >(Could a language be designed that would preserve some measure of portability
> > across some set of supercomputer systems while allowing maximal control and
> > performance? ...)
> 
> Answer:  Yes.  It will not be easy; it will certainly not be C; and
> it may have a small value for `maximal control'.  But there is no
> theoretical bar, just lots of practical ones.
> -- 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
> Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris

Of course, one should be able to describe the problem in straightforward
terms and have the compiler produce optimal code :-).  That we cannot now
do this is merely a practical problem.  So your sorting problem is trans-
lated by the compiler into the O(n^2) worst-case code.  Now we all know that
that is the wrong way.  But suppose that I know that it is extremely unlikely
that there are more than a very small number of items will have to be moved
up more than a small amount?  Then it is the right way.

There are algorithms which are highly portable.  There are algorithms which
are moderately portable.  There are algorithms which look like they are 
portable, but the portable code crawls.  There are situations where the
aim of the algorithm is portable, but a portable algorithm is a total waste
of machine time.  These are not theoretical bars, just practical ones.

The quantity and diversity of the practical bars are such as to cause me to
suggest that we do not try for perfection, but for versatility.  


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (ARPA or UUCP) or hrubin at purccvm.bitnet