Fortran vs. C for numerical work (SUMMARY)

[Brian Glendenning]

A few days ago I posted a note asking:

>It is often stated that Fortran is better than C for numerical work. I
>am interested in compiling both the standard list of such arguments
>and what any counterarguments might be.

Here is my summary of the responses I received. If anyone wants to
read the raw responses please email me and I will be happy to forward
them (160k+!). Many thanks to all the respondents who so generously
answered my query.

1. Pointer aliasing.
     SUBROUTINE FOO(A,B)           void foo(a,b)
     REAL A(*), B(*)               float *a, *b;

The fortran standard requires that A,B be unaliased. In C a,b may well
be aliased, and there is no portable way to say that they are unaliased.

Compilers on serious vector machines (at least) will have ways of
declaring unaliased pointers. The programmer can make a mistake doing
this, but of course the programmer can also really pass aliased arrays
in Fortran as well. Although I understand that "noalias" is hated by C
purists, I wish that it had made it into the ANSI standard. (Maybe I
just don't understand the arguments against it).

2. C has no conformant arrays, i.e. you can't do the equivalent of:

      SUBROUTINE FOO(A, M, N)
      REAL A(M,N)

In C you either have to do your own indexing *(a + j*m +i) or have
pointers to pointers *(*(a + i) + j). You can in either case
use a macro expansion ARRAY(a,i,j) to take some of the sting out of
the syntax.

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

I think that ANSI C has a method by which compilers may make sin, cos
etc intrinsic, but I don't remember how it works. Maybe a wizardly
followup could answer this question.

A ** builtin _is_ handy.

4. Fortran has complex variables.

If you need to do a lot of complex arithmetic this might be a show
stopper unless you have a good source of C complex arithmetic
routines. Even then it is not going to be as convenient as in Fortran.

5. There are many numerical libraries written for Fortran.

This is likely not a fundamental problem on any modern system
scientific programmers would use, e.g. either use f2c to convert it or
link in the fortran, but it does impose either some programmer time
overhead in the translation or make the linking process (at least) a
bit non-portable.

6. C can ignore the placement of parentheses
7. "C has too many system dependent aspects (e.g. round up or down when
   dividing negative integers)."

Both of these need to be understood by a scientific programmer so they
can work around them.

8. C does everything in double.

Not (necessarily) with ANSI C.

======

I will not go into the reasons why C was claimed to be better for
numerical work Fortran (basically better data typing, control
structures, dynamic memory etc).

_MY_ sumarry-summary is as follows:

I conclude that for scientific programming there are no overwhelming
reasons not to use C unless you do a lot of complex arithmetic.

Personally I don't consider the "pointer aliasing defeats optimizers"
to be too serious. Anyone who cares about speed is going to profile
their code, and at that time it shouldn't be too difficult to tell the
compiler what is not aliased in the "hot spot" routines.

Whether or not the switch to C is worthwhile will depend on whether
the above quirks in C outweigh the benefits of having "more modern"
data typing and control structures. Fortran is probably more portable (*)
and will run faster without tweaking. On the other hand Fortran may be
harder to maintain, and it is a poor fit to algorithms that are best
expressed with types more involved than n-dimensional arrays.

(*) 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.

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).

Brian

--
       Brian Glendenning - National Radio Astronomy Observatory
bglenden at nrao.edu          bglenden at nrao.bitnet          (804) 296-0286