Should I convert FORTRAN code to C?
Walter Bays
walter at garth.UUCP
Fri Jun 10 04:15:42 AEST 1988
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
------------------------------------------------------------------------------
More information about the Comp.lang.c
mailing list