Xref: utzoo comp.lang.fortran:5800 comp.lang.c:40510 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!modus!otello!gear!cadlab!martelli From: martelli@cadlab.sublink.ORG (Alex Martelli) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Fortran and C performance (was: NAG Fortran 90 announcement) Message-ID: <911@cadlab.sublink.ORG> Date: 26 Jun 91 08:00:44 GMT References: <15634@exodus.Eng.Sun.COM> <26334@lanl.gov> <26453@beta.gov> Organization: CAD.LAB, Bologna, Italia Lines: 98 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).