Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!think.com!yale.edu!cmcl2!beta!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: NAG Fortran 90 announcement
Message-ID: <26453@beta.gov>
Date: 25 Jun 91 18:54:19 GMT
References: <15634@exodus.Eng.Sun.COM> <26334@lanl.gov> <PRZEMEK.91Jun24225047@rrdstrad.nist.gov>
Sender: news@beta.gov
Organization: Los Alamos National Laboratory
Lines: 77

In article <PRZEMEK.91Jun24225047@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes:
|> [...]
|> I understand that Jim is known for his dislike of UNIX and C, so I suppose
|> that I shouldn't be surprised by his criticism. However, I have to object to
|> his claim that C is pessimizing the array calculations. Au contraire, it is
|> well known that some of the optimizations used to treat multidimensional
|> arrays in Fortran are much easier expressed in C---strength reduction in 
|> index calculations, for example, is naturally expressed in C by having a
|> pointer to the column (row in C, actually). As far as I can tell, Fortran
|> could only do it by static (compile time) equivalence. 

It is well known that a lot of C bigots promote that myth.

It is also well known that a state-of-the-art compiler does not need 
the user to "express" anything in order to do these optimizations.  
Strength reduction in index calculations, for example, has been done 
in Fortran compilers for over 30 years now (that's right, IBM had a 
proprietary compiler in the early 60's that could do it).

The pointer to the row that you talk about C using is the type of
pessimization that I'm talking about.  In C, the compiler must assume
that all pointers are _aliased_ to one another.  This means that a
simple loop to swap two rows can't be optimized in C because the
C compiler can't tell whether the two row pointers are aliased or
not.  Further, the pointer-to-pointer-to-...-row implementation
is only efficient if you access your multidimentional array in 
the same order as it's declared.  If (and many numerical algorithms
_require_ this) you have to traverse your array sometimes in row
order and sometimes in column order in the _same_ code, you will
have an extra address fetch in the inner loop part of the time.

The fact that C turns _all_ arrays (regardless of dimensionality)
into pointers in the procedure call mechanism means that C must
always assume that array parameters are mutually aliased and can't
optimize operations on them.

All known optimizatation techniques are inhibited to some extent
or other by aliasing.  On vector or massively parallel machines, 
the presence of aliasing may mean factors of _hundreds_ in performance.

|> [...]                                                           As
|> to the former, let me tell you about my own experience: my friend had
|> a hydrodynamics code in Fortran (many array accesses!). I have heard
|> rumors that people observed speedups on their fortran code by
|> translating to C (using f2c). [...]

Yes, many Fortran compilers (especially on UNIX) are _junk_.  Many
UNIX Fortran compilers are actually front-ends to the C compiler's
code generator.  Since, in this arrangement, the backend was tuned
to produce good code for _C_, it does not do well for the different 
constraints that Fortran entails.  So what?  Outside of UNIX, it is
well known that Fortran is usually _much_ faster than C.

|> [...]                        I tried f2c; the result was that the C
|> code after the automatic translation was 10% slower. [...]

The Fortran Journal published a benchmark on f2c a few issues back.
As I remember, the average slowdown was about 15%.  The benchmark
was done on minis or micros and didn't show the enormous slowdown
you'd expect on a vector machine or a massively parallel machine.

|> [...]                                                       I do not
|> know of a good way of expressing such things in Fortran (flameproof suit on)

I don't know that you should be flamed.  You admitted you didn't know.
That's a far cry from the usual C bigot who claims he _does_ know and
then spouts a lot of false statements.  As for linked lists in Fortran,
a lot of us have been doing them for years.  Unfortunately, we've had
to either use non-standard extensions or we've had to pre-allocate
the maximum required memory.  Even so, most Fortran implementations
have the necessary extensions.  The Sun Fortran compiler has Cray 
style pointers in it (as do several other of the better class of
UNIX Fortrans).  Fortran 90 will also allow such things as a standard
capability (with a pointer facility which has very _bad_ interactions 
with the whole array features of the language).

J. Giles