From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: Fortran to C issues?
Organization: MacNeal-Schwendler Corp.
Date: Tue, 17 Nov 92 22:43:50 GMT

In article <BxtKJL.2Ir@accelr8.com> jim@accelr8.com (Jim Reiss) writes:
>In some computation-intensive environments there seems to be a general
>feeling that FORTRAN is much better than C for some tasks.  I shudder to
>be asking this because rekindling the C/FORTRAN flame war is not what
>I want to do...but...is there a good basis for that opinion, and does that
>mean that FORTRAN to C translators like f2c and the NAG FORTRAN compiler
>are inherently inferior to a FORTRAN to machine language compiler?  If so,
>please explain why.  Please try to keep answers from degenerating into
>"so there" and religious style comments.  Thank you.
>-- 

One reason has to do with the compiler's ability to *understand* the
code and its ability to optmize.  As an example, Fortran specifically
_prohibits_ more than a single argument to a subroutine to *define*
a value (i.e. equivalence associations may not occur through the
argument list).  The compiler is then able to gain additional information
about the code.  C relies very heavily on pointers which could point to
anything, thus the complier can glean (glomm?) much less information
about the code, so some optimization will, at very least, _appear_ to
be unsafe.  Glancing at a *typical* (what's that?!?) C function, one often
sees more than one pointer to the same location being used in different
contexts.  Some C compilers admit command line options or #pragma's to
allow the programmer to provide such hints.

Another (historical) reason had to do with the K&R definition of C 
that demanded *implicit* promotions in argument lists and required 
float operations to be done in double mode.  If you're only doing an 
occasional float operation, what's the big deal?  But, try writing a 
single-precision (half-precision?) matrix utility, and you can 
imagine the performance hits.  Fortunately, ANSI did away with that 
particular thought pattern when function prototypes are used.  Always
Prototype!

Next, there is the problem of passing multi-dimensioned, assumed-size
arrays, C doesn't!  While there are many, games you can play to deal
with the issue (see in particular "Numerical Recipes in C"), it's
still a nuisance.

Finally, and this will change with time, Fortran compiler writers have
more experience in highly optimized code than do C compiler
writers.  That's a temporary advantage at best.

On C's side, have you ever seen code which dealt with bitmaps, free
memory chains, complicated structures and the like in Fortran?  Talk
about terminally ugly and begging for coding errors!

So, the *best* language depends on what your needs are!  The choice
of *best* need not be a single value for a given project.  Depending
upon what the application is, I will argue for anything from _pure_
Fortran, to a mix of Fortran and C, to _pure_ C!

Now for things like f2c, the NAG F90 and Vienna Fortran compilers (this 
also applies to C++ when implemented as a font-end to a C compiler).  
These systems insert another layer of translation between the 
programmer's original source and the target (i.e. machine language).  
Clearly the front-end compiler can obscure the original code and 
introduce additional constructs which may degrade optimization.
How much the code is degraded depends upon how much effort 
the authors of the higher-level compiler put in to understanding the 
requirements of the target compiler.  To be fair, the higher-level
compiler writers could also enhance performance by performing analysis
which the target compiler _should_ have performed, but didn't!

Please do not misunderstand me, there _is_ a place for these systems
too, but I wouldn't want to compete against a good (maybe even
mediocre in some instances) native compiler.

So, as in all things, there are not absolutes!  You must evaluate _your_
requirements and somehow match these to the options available to _you_.

Regards,
DNL

                 MY_COMMENTS = MY_OPINIONS = NOBODY_ELSES

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041