Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pioneer!eugene
From: eugene@pioneer.arpa (Eugene N. Miya)
Newsgroups: comp.arch
Subject: Re: FORTRAN Horror
Message-ID: <6321@ames.arpa>
Date: 22 Mar 88 22:01:29 GMT
References: <24861@yale-celray.yale.UUCP> <1135@pembina.UUCP> <2596@pdn.UUCP>
Sender: usenet@ames.arpa
Reply-To: eugene@pioneer.UUCP (Eugene N. Miya)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 68

In article <2596@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes:
>
>The other reason is that FORTRAN programmers are interested in raw
>performance above all else. . . .
>numbers using 64-bit reals?  They'll just make a copy of the one for
>32-bit reals and use the editor's global replace to change the data 
>types as appropriate.  Of course, all code is written for maximum 
>performance on the machine which will be used to run it.
>
>Performance is an OBSESSION with these people.

I just came from a meeting (where several other comp.arch readers were
present) where these issues were discussed as part of an evaluation
of programming languages (not all functional) for high performance
computing.  Discussion was most interesting.

Harry Jordan (a numerical methods person from the Univ. of Colorado]
in some comparisons on functional languages, walked out of the room,
was not willing to hear people who would not consider performance
as an overriding feature of languages.

Sure they have reasons for their obsessions:
1) Some of the science in these codes is an attempt to stand on the
shoulders of colleagues and past science (read physics).  We call them
dusty decks some time.
As an example we heard from an end user of powerful machines:
2) Jack Hack, an atmospheric physicist from NCAR 
[e.g., where or uuhosts -a hao] points out that weather is not just a 3-D
problem.  You just don't edit the constants in weather models, new
variables emerge when you go to finer resolutions.
This talk was interesting because it was one where all the computer
people could relate (weather).

David Kapholtz (Columbia) suggested there was a degree of arrogance
in the not-to-be moved insistence on Fortran.

Consider an example, not given by Hack:
There are two kinds of value from a weather code: the predictive
and the descriptive.  A code which takes 27 hours run time to make a 24
hours forecast is bound to provoke snickers, but if the science is
correct, then the descriptive value only needs minor tuning.
The issue then is only performance (sorry, they are a bit short sighted
since portability is a minor issue).

The temptation to let compilers "do it all" [compiler overloading] with
EXISTING languages is very high.  So this gives Kuck Associates in Ill.
and Kennedy at Rice lots of money.  The computer community would
otherwise have to band together to push new languages: [If you want new
levels of performance, you are going to have to use XXX, where the
Connection Machine or hypercubes are something of good examples
(terrible to program, can you say 1946?)].

Your target has to be young researchers (physicists and others) who don't
have vested interests in older existing codes.  (See the work by Wolfram
and other rogues of science.)  This is why it is
important in grad school to mingle at lunch with people outside your
discipline (See Feynman's autobiography as an example of this).

I bet you didn't see the relation between languages, architectures, and
applications and having lunch with colleagues in other disciplines
to understand their problems? ;-)  Don't push it, but it is important.
But, let's get back to architectures and why we build them. 8-)

From the Rock of Ages Home for Retired Hackers:

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  "Send mail, avoid follow-ups.  If enough, I'll summarize."
  {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene