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

[Chris Torek]

>>In article <719 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>>>As long as programmers are taught to think in terms of a language, rather
>>>than the machine, it will be difficult to get vendors to allow the forcing
>>>of inline.

>In article <10763 at mimsy.UUCP> I answered with
>>As long as programmers are taught to think in terms of a machine,
>>rather than the language, it will be difficult to get portable code
>>that can be moved to that 1 teraflop computer that will come out
>>tomorrow, then to the 10 teraflop computer that will come out the day
>>after, and then to the 100 teraflop computer that will come out a week
>>from Monday.

In article <5308 at hall.cray.com> pmk at hall.cray.com (Peter Klausler) writes:
>A routine written for optimal performance on one architecture may be coded
>so that it is portable to others, but it'll be optimal on only the one.
>Write for optimal performance on a VAX and your code will crawl on a Cray.
>Code for maximal portability and you'll be suboptimal everywhere, having
>reduced yourself to a lowest common denominator of machine.  Compilers can
>hide lots of annoying differences, but they can't change a nifty linked
>VAX-optimal data structure into a simple vectorizable Cray-optimal array.

This is true.  That is, it is true now, and it has been true in the
past, and no doubt it will be true in the future.  Yet I claim that
whenever it is true, that means only that you are working in too low
level a language.

For instance, it is certainly the case that if the language were at the
absolute top level of the problem (`compute the answer to this
question'), and the `compiler' for this produced decent `code'
(referenced the program written specifically for that machine that
solves that problem), the program would be portable (`find the
input-value-th digit of e' is perfectly portable) yet still optimal.

As another example, it has always surprised me that supercomputers do
not come with good APL systems.  APL is one of the few languages where
one can write what one means when dealing with matrices.  (It has other
problems, but I think it has a place here.)  I would hope the matrix
multiply routine for the Cray would be reasonably close to optimal,
even though it would no doubt be quite different from the one on the
VAX.  The programmer does not have to deal with the difference:

	A <- B * +/ C

portably says to multiply B by the (scalar) sum of all the elements
of vector C and put the result in A.

>... 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!  The VAX assembly bcopy() routine is
not portable, but use of it is.  Perhaps you can hide your fast but
machine specific code in a subroutine.  More likely you will need
a smarter compiler and/or higher level language.

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