C vs. FORTRAN

[Jim Giles]

>From article <517 at chem.ucsd.EDU>, by tps at chem.ucsd.edu (Tom Stockfisch):
>>> is more important that a shaved MIP.  [...]
>> In that case, Fortran is certainly a better choice than C for most
>> numerical computations.
> 
> I have to disagree.

Fine.  Just don't try to force _your_ decision on anyone else.

>> Fortunately, it also helps if you're after shaving a few MIPs as well.
> 
> That's not true on most of the machines I use.  [...]

It is for most of the machines _I_ use - by a LOT!  In C, every pointer
(and, therefore most arrays) must be assumed to be aliased to every
other pointer.  Code must be generated under this assumption.  In Fortran,
all objects are locally declared (even non-local objects), so the compiler
_knows_ which are aliased to which.  Since aliasing can inhibit most
optimizations on pipelined, parellel, and vector machines, C is clearly
slower on such machines (unless unsafe optimizations are performed).
Aside from this difference, C and Fortran are equally difficult (or easy)
to optimize - and the same optimization techniques work for both.  The
only places I've ever seen C beat Fortran are _very_ simple machine
architectures (no pipelining, etc.) or on small machines where the
compiler omits most optimization techniques to make the compiler small
enough to fit on the machine.

>> Consider, for example, a routine to do matrix multiply
>> on arbitrary sized and shaped matrices - both C an Fortran require the
>> programmer to express the iteration explicitly, but only C requires the
>> index calculations to be done explicitly.
> 
> Not really.  You can either use a macro, [...]

Why should I have to declare a macro for something Fortran has built-in?
Doesn't sound like an advance to me.  Besides, I have used macros in
Fortran for years.  The advantage with Fortran is that I _start_ with
a more complete array syntax.

> Or, better, use a storage allocator that returns a pointer to the
> first element of an array of pointers, each of which point to a row
> of your matrix.  Then you have [...]

A multidimensional array is _NOT_ an array of pointers to pointers to ...!
Implementing it this way slows down all array accesses by the number
of indirections required.  Further, since each of the pointers in a
pointer array is assumed to be aliased to the others, optimization is
_really_ squashed.  A good compiler will move the indirections out of
middle loops (if you have a NOALIAS directive it will), but they still cost.
Fortran 8x will have allocatable arrays which will allow portable dynamic
arrays to be declared without _any_ multiple indirection overhead.  In the
meantime, it is cheaper to recompile with different sizes than to pay for
the overhead on a large numerical code.

> Sparse matrices are also easier in C.

I've heard this claim before, but I've never seen any advantage of either
language for this.  In either case, the programmer must code a lot of index
calculations - the only difference is whether the calculated index is
added to a pointer or used as a subscript - big deal.

> [...]
>>when will we see a Fortran++ ?
> 
> It would have to be called "      FORTRAN = FORTRAN + 1.0E+00".
> I think its a bad idea to make a new language upwardly compatable
> from the Original Language.  When will we see Fortran die and fade away?

I agree that backward compatibility is a double-edged issue.  C++ would
have been _MUCH_ better if they had eliminated pointer-array equivalence,
but then it wouldn't have been backward compatible.

As for when Fortran will die - well if languages die in order of design
quality (with lowest quality dying first) then Fortran will die after C
does.  Unfortunately, the success of a programming language seldom has
much correlation with the quality of the language.  So, I think Fortran
will die with the introduction in 8x of the world's worst pointer facility.