Path: utzoo!mnetor!uunet!husc6!yale!lisper%thor
From: lisper%thor@CS.YALE.EDU (Bjorn Lisper)
Newsgroups: comp.arch
Subject: Re: Was: RISC is a nasty no-no! More to the point: Supercomputer addresses
Message-ID: <24876@yale-celray.yale.UUCP>
Date: 10 Mar 88 17:25:24 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP: <284@scdpyr.UUCP> <24605@yale-celray.yale.UUCP> <7690@pur-ee.UUCP> <24737@yale-celray.yale.UUCP> <24861@yale-celray.yale.UUCP>
Sender: root@yale.UUCP
Reply-To: lisper%thor@CS.YALE.EDU (Bjorn Lisper)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 44

In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry
Leichter) writes:
>In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn
>Lisper) writes:
>>... If we had a language that specifies nothing but the
>>functionality of accessing an array element, that is: the only thing we know
>>about a(i,j) is that it returns the current value of a(i,j) when referred
>>to, then an optimizing compiler for that language would have much more room
>>to play around with different storage orderings in order to minimize access
>>time. Isn't this a nice argument against using a language like FORTRAN in
>>scientific computing?
>
>Nice theoretical argument - but it ignores the central issue:  Maybe the
>REASON the scientific community like FORTRAN is that it ALLOWS them to "play
>around".  In fact, such "playing around" is an absolutely standard technique
>in many large numerical codes; it's what makes them practical. ....
....
>Before proposing to remove something so central to large codes, you'd better
>understand WHY it's central, and what you can provide to replace it with.

And maybe the reason why people want to have total control over memory
management as in FORTRAN is that there have been no compilers for other,
less memory-explicit languages that have produced good code? A great deal of
the development of parallelizing compilers for supercomputers have been
development of FORTRAN compilers, for natural marketing reasons.
Unfortunately, for the reasons I pointed out, there is a limit to how smart
these compilers can be. So as long there is no real effort put into
developing good parallelizing compilers for more high-level languages the
art of parallelizing & optimizing compiling will not develop to its full
potential.

Another issue is of course portability; FORTRAN code hand-tailored for one
machine will perhaps not perform too well on another (since the compiler
cannot alter the programmer's detailed decisions), while for a higher-level
language more decisions are left to the compiler. But this is an old story...

Anyhow: I have full understanding for that people who needs top performance
in supercomputing today use FORTRAN; they haven't got very much else to
choose from. But as long as people stick to this language there is a limit
to how good the compilers can be.

Maybe this isn't a comp.arch discussion anymore?

Bjorn Lisper