martelli@cadlab.sublink.ORG (Alex Martelli) (06/26/91)
jlg@cochiti.lanl.gov (Jim Giles) writes:
...
:|> to the former, let me tell you about my own experience: my friend had
:|> a hydrodynamics code in Fortran (many array accesses!). I have heard
:|> rumors that people observed speedups on their fortran code by
:|> translating to C (using f2c). [...]
I believe I am the first who posted such a result to the net, for a
computational benchmark on Sparc processors using compilers that were
current more than a year ago; as I recall, others tried other tests
with similar results on other machines. For what it's worth...:
:Yes, many Fortran compilers (especially on UNIX) are _junk_. Many
...I fully agree with Jim's assessment of the situation; it's just
absurd, on the face of it, that a two-step compilation going through
another high-level language, without manual intervention, should
produce BETTER code than straight compilation to machinecode!
:UNIX Fortran compilers are actually front-ends to the C compiler's
:code generator. Since, in this arrangement, the backend was tuned
:to produce good code for _C_, it does not do well for the different
:constraints that Fortran entails. So what? Outside of UNIX, it is
:well known that Fortran is usually _much_ faster than C.
Unfortunately MSDOS, OS/2, and from what I hear such boxes as Mac,
suffer from the same ailment, particularly now that Zortech has put
on all of them their superduper optimizing C/C++ (whyohwhy don't they
make me a FORTRAN compiler of the same quality, sigh!).
I believe you may have been referring to such machines as supers and
mainframes, and in the period I used those heavily, say up to '88, it
was definitely true - surely for automated fortran->C translation, or
one done manually but without deep understanding of both the application
code and the C language, at least.
Current situation is less clear. I have experimentally recoded pieces
of VAX/VMS Fortran into C, manually and with great care, obtaining good
speedups for non-computational tasks. Examining the resulting machine
code, it appears as if Vax Fortran is trying very hard to make use of
the VAX's complex instruction set, while Vax C appears to be using a
simpler subset, and concentrating instead on register optimization, with
some code-generation help from by-value passing of input parameters and
by-reference passing of character strings, while portable Fortran has
one inevitable further indirection, going by-reference for numbers and
by-descriptor for character stuff. I suspect that on the machines I
(and most of my customers) have at hand, typically Vaxstation 3100's,
the 'risc subset' of the Vax architecture is better implemented, and
CPU and registers are FAST relative to memory; i.e., I might NOT get
the same timings on, say, a venerable 780.
I assume that on supercomputers the no-aliasing constraint of Fortran
IS still allowing better code generation, but I have no recent experience.
:|> [...] I tried f2c; the result was that the C
:|> code after the automatic translation was 10% slower. [...]
:The Fortran Journal published a benchmark on f2c a few issues back.
:As I remember, the average slowdown was about 15%. The benchmark
:was done on minis or micros and didn't show the enormous slowdown
:you'd expect on a vector machine or a massively parallel machine.
Now these 10-15% slowdowns, as the price to pay for an intermediate
high-level language without any manual intervention, appear to me
FAR more reasonable than any speedup, in line with most of my own
tests, and still a great result for f2c. Consider that a little
manual twiddling, such as eliminating unwanted pass-by-reference and
maybe strategic placing of "register" and macros in lieu of subroutine
calls, can easily buy you back that much, or more.
As I said, I can't speak about supers from direct recent experience.
Can't somebody with access to, say, a Convex, grab f2c from AT&T's
netlib, try some simple codes, and let us KNOW...? I would indeed
assume that the situation would be quite different (or, what are all
the fine folks in the C Numerical Extension group sweating FOR, if
not to remedy some performance inadequacies of C vs Fortran?!).
:|> [...] I do not
:|> know of a good way of expressing such things in Fortran (flameproof suit on)
:I don't know that you should be flamed. You admitted you didn't know.
:That's a far cry from the usual C bigot who claims he _does_ know and
:then spouts a lot of false statements. As for linked lists in Fortran,
:a lot of us have been doing them for years. Unfortunately, we've had
:to either use non-standard extensions or we've had to pre-allocate
:the maximum required memory. Even so, most Fortran implementations
:have the necessary extensions. The Sun Fortran compiler has Cray
:style pointers in it (as do several other of the better class of
:UNIX Fortrans). Fortran 90 will also allow such things as a standard
:capability (with a pointer facility which has very _bad_ interactions
:with the whole array features of the language).
For some of us, nonportable code is NOT an option - why, I can't even use
ANSI-C features, since quite a few platforms still don't implement them,
or not correctly! I *want* to keep alive the Fortran codes we have, and
I dearly hope that F90 or some other magic wand will enable me to do so,
but on present trends in performance and general compiler quality, on the
boxes we support (Unix, VMS, PCish stuff, etc), it's becoming harder and
harder to defend this choice...
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).nather@ut-emx.uucp (Ed Nather) (06/27/91)
As a point of reference, we use a Discrete (Slow) Fourier transform program a lot. The original was written in Fortran, carefully structured for speed at the source code level. Some time ago the original author decided to learn C, and used the DFT as a way to do so. He re-coded the program in C that had a strong Fortran accent. It ran 25% faster. The Fortran: Microsoft for the IBMPC. C: Borland's C++.