Fortran vs. C for numerical work (SUMMARY)

[Dan Bernstein]

Summary: Each of the disadvantages that Brian mentions for C as compared
to Fortran should disappear within a few years without any further
standardization. In the same areas, Fortran has many big disadvantages,
each of which will be quite difficult to fix.

In article <BGLENDEN.90Nov26162335 at mandrill.cv.nrao.edu> bglenden at mandrill.cv.nrao.edu (Brian Glendenning) writes:
> 1. Pointer aliasing.

If you allow interprocedural analysis, the compiler can detect the
``aliasing signature'' of every call to a function, and generate
separate versions that run as fast as possible for each signature.
If, in fact, no aliasing is present, the compiler will generate just one
version. So this is only a temporary disadvantage---when C compilers get
smarter, they'll be able to generate just as fast code as Fortran (at
the expense of somewhat slower compilation).

In my experience, pointer aliasing in C is an advantage. I don't have
to, e.g., write two versions of a large-number addition routine, one
where the output overlaps the input and one where it doesn't. The price
I pay for this is that most current compilers only generate the slower
version (so in speed-critical applications I'm now forced to write two
versions, one using some unportable assertion like ``noalias''). But a
smarter compiler could do the job. The extra compile time is worth the
programming time saved.

This disadvantage of Fortran (that it doesn't allow aliasing at all) is
much more difficult to fix. Even if a compiler appears that allows
aliasing, code taking advantage of it won't be portable. So nobody'll
bother.

Part of the flame war in comp.lang.misc is over my contention that the
compiler can do a respectable job of aliasing detection *without*
interprocedural analysis---by generating a small, static set of
signatures and working with those. But this is a side issue.

> 2. C has no conformant arrays, i.e. you can't do the equivalent of:
  [ ... ]
> In C you either have to do your own indexing *(a + j*m +i) or have
> pointers to pointers *(*(a + i) + j).

I agree that this is a problem. However, the double-pointer solution
usually allows faster access than the standard method of storing arrays,
doesn't waste much memory, allows more flexibility, gets around the
memory management problems of some small architectures, and lets you use
a[i][j] for *(*(a + i) + j), all within current C. It is extremely
difficult to do this efficiently in Fortran, and it will continue to be.

In some applications, though, dynamically sized flat multidimensional
arrays may be better than multiple-pointer arrays. At least one very
popular current compiler, namely gcc, lets you declare arrays the way
you want.

> 3. In fortran functions like sin, cos, ** are intrinsic.

Fortran and ANSI C treat intrinsics the same way.

> 4. Fortran has complex variables.

Given the number of inlining compilers, this is at most an issue of what
syntax you prefer. Many programmers don't like infix notation for
operations that are generally simulated by the compiler rather than
executed directly by the machine. For them, Fortran is at a
disadvantage here. This is hardly a major issue, though.

> 5. There are many numerical libraries written for Fortran.

Which, given f2c, is no longer an issue.

> 6. C can ignore the placement of parentheses

ANSI clamps down on this.

> 7. "C has too many system dependent aspects (e.g. round up or down when
>    dividing negative integers)."

Huh? Fortran has system-dependent aspects too.

Fortran does not have standard I/O powerful enough to, e.g., respectably
checkpoint a computation. This is a huge disadvantage. It will not be
fixed except by further standardization.

> 8. C does everything in double.

ANSI fixes this cleanly.

> (*) I realize that it is not that hard to write portable C. I think
> it's fair to say that it's easier to write portable Fortran for
> numeric work, though.

In my experience with numerical code, it has been extremely easy to
write portable C. Numerical programs use input and output too.

> When and if we have fortran9? available the story may be different
> (but it's getting pretty late in the day for F9x to come riding over
> the horizon to save us).

Fortran 8X: the teenage mutant ninja offspring of Modula-2 and Ada. A
few years ago I was in a room full of Fortran programmers listening to a
presentation about the language. They hated almost everything about it.
Now it's Fortran 9X and still somewhere over the horizon.

C is a de facto standard. ANSI C is a standard. So is Fortran 77. The
new Fortran is not. C, ANSI C, and Fortran 77 are the language variants
that will be widely used over the next several years, and those are the
languages we should be comparing.

---Dan