Should I convert FORTRAN code to C?

[Walter Bays]

jlg at beta.UUCP (Jim Giles) writes:
>Most code (new and old) in major scientific computing environments is
>Fortran, even when C is available.  Whether this is because Fortran is
>actually superior, or just programmer inertia is a question that spurs
>that 100-years war you complained about.

paolucci at snll-arpagw.UUCP (Sam Paolucci) writes:
>Ah!  Most major scientific computing environment use CRAYs as their
>CPU.  Do you know of a good C compiler on the CRAY that produces code
>of somewhat comparable performance as CRAY's Fortran compilers?
>There, I suggest, is part of the answer.

   I would venture that most C compilers have not produced code that is as
   fast as most Fortran compilers.  And even as the computer industry
   continues doubling hardware performance, scientists like Jim Giles
   immediately use the new power by expanding the range of problems
   studied - and ask for more.  Software efficiency will always be
   important to them.

jlg at beta.UUCP (Jim Giles) writes:
>Here you are putting the cart before the horse.  There was no C compiler
>for Crays until recently because there was no demand for it.  The present
>demand is almost entirely from within Cray and from other (non-scientific)
>Cray customers.  Again, whether this is from inertia or valid preference
>is a combative issue.

   A chicken and egg problem.  IF excellent C compilers had been
   available, would they have used them?  Probably so.  IF user demand had
   been present, would Cray (and others) have provided C compilers as fast
   as the best Fortran compilers?  Probably not.

   C provides lower level primitives which a programmer can use to write
   fast code.  So the worst C compilers are better than the worst Fortran
   compilers.  But C's liberal assumptions about memory volatility and
   aliasing have interfered with many optimizations that are fairly easy
   to do on Fortran.  So the best Fortran compilers are better than the
   best C compilers.
   
   Hence we have ANSI C and the battles over volatile (in the language)
   and noalias (rejected).  Chris Torek captured the essence of the
   'volatile' debate in many dozens of notes.  If you personally have no
   use for 'volatile', but would like to see C displace Fortran (perhaps
   to protect yourself from having to use Fortran :-), read Chris' entire
   note.

chris at mimsy.UUCP (Chris Torek) writes (Subject: volatile: a summary):
>Is the [volatile] keyword necessary?
>No.  (As an existence proof, consider compilers that do not now have
>the keyword.  Most of them work by not doing much in the way of
>optimisation.  There is more to it, though.)
>    Summary of the summary:
>Is the concept necessary?	Yes.
>Is the keyword necessary?	No.
>Is the keyword useful?		Yes.
>Is the keyword a `good thing'?	Opinion: yes.

jlg at beta.UUCP (Jim Giles) continues:
>I use Fortran mostly because I know how to use it WELL.  To some
>extent, the lack of detailed knowledge of C is my reason for not using
>it. (For example: why is 'a+=b' faster than 'a=a+b'?  Seems to me that
>the two are identical and should generate the exact same code.)  ...

   If you're a Fortran programmer and have not tried C because you KNOW
   its' too slow, look again.  Many C compilers have been getting much
   better, even before ANSI.  Any good compiler will generate the same
   code for those constructs.  There's a lot of folk wisdom about how to
   get around the pcc code generator and write fast C code.  (Absolutely
   essential to such things as writing systems code.) Unfortunately, much
   of this wisdom is counter-productive today, because it obfuscates the
   code and interferes with the work of the optimizer.  (Example:
   indiscriminate 'register' declarations steal from the compiler's pool
   of allocatable registers.)

swarbric at tramp.Colorado.EDU (Frank Swarbrick) writes:
>As for C not generating inline code for stuff like x = pow(x, 2); that is
>just not "C's way."  It has been discussed a lot in comp.lang.c.  Some people
>think C should generate inline code for it, and some do not.  So far, it
>doesn't.

   C compilers are starting to do more procedure inlining.  The widespread
   use of the Dhrystone benchmark has accelerated this trend, since
   inlining strcpy() and strcmp() produce much higher Dhrystone numbers.
   (The Dhrystone rules forbid inlining, but many people only care that
   the program executes correctly - and don't care what the compiler
   does.)

   On some RISC CPU's (not ours) multiplication is a procedure call that
   is sometimes inlined.  Who cares?  That affects performance, certainly,
   but the bottom line of performance is all that matters.

jlg at beta.UUCP (Jim Giles) provides an appropriate postscript:
>Fortran does some things better, C does others, and both contain deficiencies.
-- 
------------------------------------------------------------------------------
I said it, not them.
E-Mail route: ...!pyramid!garth!walter		(415) 852-2384
USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303
------------------------------------------------------------------------------