jim@interet.UUCP (User) (08/23/90)
The purpose of this posting is to state our opinion that the f2c product from ATT actually works and fills a real need, and to encourage other sites to publish their experiences and any benchmark data they may have. Because of the length of this posting, our benchmarks will follow in a few days. We write software in mixed Fortran and C which must run under Unix minis, Unix work stations, MS-DOS using DOS Extenders, and on PC coprocessor boards. Our experience has been that Fortran is a second class citizen on these hardware platforms. The Fortrans available lack the right "flavor", often are buggy, and the IO suffers from C-itis. Examples of bugs we have seen over the years are failure to clear the whole record when an ERR= branch is taken during a Fortran read (the next read gets the rest of the record instead of the next record), writing an ending zero byte when strings are written with the "$" format to suppress the ending carriage return, IO which is 2 or 3 times slower than the same operations written in C, failure of DO loops when one of the elements is a function call, total lack of error messages for "obvious" errors such as obvious uninitialized variables and subrou- tine interface errors, no diagnostics for errors in format statements (flagged during execution instead of at compile time), absence of library support to control floating point exceptions, poor documentation for vari- able Fortran features such as OPEN statements, and absence of bounds checking option. Let me admit my prejudice. I actually LIKE Fortran. I like C too, and I like C better for certain things, but there is no excuse for poor Fortran. Fortran is one of the languages that pays the bills. I am not asking for Fortran with better extensions or non-record-oriented IO (we never use non-vanilla much less non-standard features), just Fortran as good as VAX VMS Fortran, which is about ten times better than any Fortran generally available on the hardware we use. We therefore looked seriously at f2c (from netlib@research.att.com) when it became available. We had looked at Fortran to C translators in the past, but they were designed to convert Fortran to readable C on a one- time basis, and thereafter the Fortran would be thrown away and the C would become the new source and would be maintained. We see no reason to throw out good Fortran and replace it with C. We have massive amounts of working Fortran. So far it seems that f2c is part of the solution. It is a compiler, not a translator. Although the C produced is surprisingly readable, that is irrelevant since it is not necessary to read it (consider it a debugging feature for the authors). Recent net discussion notwithstanding, IMHO no one remarks when a Fortran compiler produces "readable" assembly language output, and no one should be surprised to see C output. We are calling it a compiler because it acts like a compiler, it produces useful diagnos- tics, it results in accurate ".o" files, it has a bounds checking option and other compiler-like options, it produces and accepts prototypes, it implements the Fortran language without C-like "improvements" but with "standard" extensions like implicit none (and implicit undefined(a-z)), tabs a la DEC (not for me), Hollerith, bit-wise .OR. etc. Our experience with the f2c compiler is that it is bug free (so far), but that our numerically intensive programs run slower with f2c than with oth- er compilers. We plan to post more complete benchmark data in a few days. To be continued ... Jim the grizzled Fortran hacker uunet!interet!jim
jim@interet.UUCP (User) (08/25/90)
Here are some benchmarks comparing the f2c compiler with two Fortran com- pilers. The benchmark program is 3,616 lines of Fortran. It is a sim- plex linear optimization engine which reads in the problem coefficients from disk, solves the problem, and writes about 30 lines of results to the terminal. This is a real-world program that we actually use. It is writ- ten in elementary Fortran, it uses only double precision floating point, no transcendental functions, and uses sparse matrix techniques. Times given are the sum of "user" and "system" time as reported by the Unix "time" command. The problem is CPU intensive, and "system" time is at most a few percent of "user" time. The program was tested on a small and a large problem. For each computer the same Fortran source was compiled using the maximum optimization level. Then the Fortran source was converted to C using f2c. Then the C source was compiled using maximum optimization. The answers agreed to the ten decimal places printed, but Fortran writes "D+02" and f2c writes "E+02". The first tests were run on a Pyramid 9810 under OS 5.0c using Pyramid Fortran 4.4.0 dated 4-28-89, and the Pyramid C compiler Ver 4.7 dated 4- 12-89. Results were: Fortran small problem: 596 iterations, 20.2 seconds, relative 1.00 f2c small problem: 592 iterations, 26.1 seconds, relative 1.29 Fortran large problem: 1860 iterations, 131.4 seconds, relative 1.00 f2c large problem: 2095 iterations, 199.6 seconds, relative 1.52 (1.35) Then the same tests were run on a Sun 3/60 under OS 4.0.3 and Fortran 1.3. Results were: Fortran small problem: 575 iterations, 44.9 seconds, relative 1.00 f2c small problem: 625 iterations, 54.5 seconds, relative 1.21 Fortran large problem: 2028 iterations, 330.5 seconds, relative 1.00 f2c large problem: 2024 iterations, 356.8 seconds, relative 1.08 Interpretation is complicated by the fact that a different number of sim- plex iterations were performed by different cases, even though the prob- lems were identical. For these benchmarks, f2c is always slower by 8% to either 52% or 35% (depending on whether total time or time per iteration is used). Jim the grizzled Fortran hacker uunet!interet!jim
jim@interet.UUCP (User) (10/02/90)
Here are some f2c versus Fortran benchmarks. They were provided
by Nhuan Doduc, Framentec-Cognitech, Paris, France. The program
is a thermohydraulic model, uses double precision arithmetic,
is compute bound, uses negligible IO, and is only 2% vectorizable.
R Values using f2c and Fortran (larger R is faster)
===================================================
Computer R f2c R Fortran Relative
-------- ----- --------- --------
Solbourne Series 5 235 265 89 %
Sun 4/110 61 74 82
Sun 4/260 81 95 85
Sun 4/20 SLC 93 103 90
Sun 4/60 SparcStation I 107 119 90
Sun 4/370 164 234 70
Note that the f2c translation is about 84% as fast as Fortran.
Nhuan Doduc wrote me to say:
"I would suggest only 2 conclusions: (1) f2c is SOLID since the doduc source is
VERY UGLY (it has broken many compilers) and (2) the doduc is a good candidate
for evaluating the progress of the work done on f2c, that is if f2c workers
want to improve their product."
Jim Ahlstrom uunet!interet!jim
Nhuan Doduc ndoduc@framentec.fr or ndoduc@cognitech.frereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (10/02/90)
great, but what we really need is c2f. -- Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase