Xref: utzoo comp.arch:4125 comp.misc:2185
Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lamaster
From: lamaster@ames.arpa (Hugh LaMaster)
Newsgroups: comp.arch,comp.misc
Subject: Re: FORTRAN Horror
Message-ID: <6630@ames.arpa>
Date: 29 Mar 88 16:58:21 GMT
References: <1135@pembina.UUCP> <46500011@uxe.cso.uiuc.edu>
Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 60

In article <46500011@uxe.cso.uiuc.edu> kelly@uxe.cso.uiuc.edu writes:

>I see a lot of people claiming that fortran is a wonderful number-crunching
>language.  In my experience, even if this assertion has basis in fact, it is
>irrelevant to your average engineering (including myself) or scientist
>programmer.  A well designed compiler will make a difference of about a
>factor of two in how fast a code runs.  This difference between a so called
>good/bad programming language would not be more than 20%.

Well, I don't know anybody who claims Fortran is "wonderful" - just better
than the alternatives.  Why?

1) Vectorizing compilers that can, in some cases, deliver performance
on a vector machine (Cray, Cyber-205/ETA, etc.) of 50% of peak
performance on a well designed code.  That might be 100-200 MFLOPS,
compared with 10 MFLOPS for a scalar version on the same machine.
The payoff is much greater than the factor of two cited above.

2) Fortran is modular.  Fortran subroutines are modules, and this puts
Fortran ahead of any language (e.g. Pascal) which only has "procedures".
Yes, both would be better.  Unfortunately, I haven't seen any vectorizing
Modula-2 compilers for the Cray or CDC machines.  Convex does sport a
vectorizing C compiler, however.

3) Fortran is not a bad programming language, even for systems programming.
Fortran has been used as the basis for a number of system implementations.
Now C bigots will note that C has modules and internal procedures, and, yes,
it does have advantages as a system implementation languages.  But, for a
Fortran replacement it is hopeless.  The syntax is confusing and more error
prone than Fortran, but even worse, because C doesn't have dynamic array
dimensioning you can't use it for separately compiled libraries like
Linpack.

>	The fact is your average engineering (including myself) or scientist
>programmer hasn't a clue how to write good fast code.  And it is almost
>certain that any reasonably large code we write, can be made run at least
>2 times faster by changing how it is coded.  It is also true that for
>99 percent of the code that we write, it doesn't matter how fast it runs,

Again, the payoff on a vector machine can be much more than a factor of
two.  True, it doesn't matter how fast most code runs.  But it does
matter how fast certain very important (to you, the user) codes run.
And now that vector machines are reaching the market of below $100 K
machines, you will have an opportunity to see which codes will run
much faster.  You may be pleasantly surprised.

>	My chief beef against fortran is that it is non portable.
>ANSI fortran is portable; but it is such a limited language, it has
>to be extended to make it useable for any large scale program.
>If you don't believe me, look at any large finite element code.  All
>of them rely on extensions to fortran 77, extensions which in most
>cases are not portable.

Fortran is intrinsically neither more nor less portable than C.  Thousands
of Fortran programmers have run Linpack programs on their machines with
no modifications.  And thousands of C programmers continue to write code
which depends on the existence of data types of certain sizes ( e.g. 16 bit
ints), on machine dependencies such as byte order, and indeed on how the
compiler will allocate the fields in a structure (just like the infamous
Fortran equivalence!)...