gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (12/19/90)
There has been an ongoing debate for umpteen years about whether Fortran or C is more appropriate for modern numerical programs. While your choice of language is often determined by what the problem needs, there have also been claims that "C isn't much worse than Fortran on even problems which Fortran well", and so on. These arguments never get anywhere because I haven't seen anyone take some real numerical applications and compare. So let's try to generate some proof. SPEC contains a bunch of programs written in Fortran which do Fortran-type things. f2c is a fortran-to-c translator which seems very robust. Anyone volunteer to run SPEC through f2c and report times for Fortran and C on a variety of boxes?
borasky@ogicse.ogi.edu (M. Edward Borasky) (12/19/90)
In article <1990Dec19.032301.4449@murdoch.acc.Virginia.EDU> gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) writes: >There has been an ongoing debate for umpteen years about whether >Fortran or C is more appropriate for modern numerical programs. Yup >While your choice of language is often determined by what the problem needs, Or your employer >So let's try to generate some proof. SPEC contains a bunch of programs >written in Fortran which do Fortran-type things. I believe that some of the SPEC codes are FORTRAN and some are "C". >Anyone volunteer to run SPEC through f2c and report times for Fortran >and C on a variety of boxes? Dumb idea! There are a number of factors that need to be isolated: 1. How efficient is the "C" code that f2c produces? 2. How efficient is the machine code that the target "C" and FORTRAN compilers produce? 3. How well-suited is the code to the architecture of the boxes in the first place, etc. As a first cut, the Livermore FORTRAN Kernels (LFK) benchmark is available in both FORTRAN and C. The C translation was hand-coded with loving care by Greg Astfalk (then of AT&T, now of Convex.) It is NOT repeat NOT a coincidence that 1. The LFK benchmark is oriented to vector machines, supercomputers and minisupercomputers. 2. At the time the conversion was done, Convex had the only WORKING vectorizing "C" compiler. 3. The FORTRAN and "C" versions have speeds on the average and on individual loops that are very close to each other. If you were to run this test on an IBM 3090VF you might see something very different. I would expect similar speeds (FORTRAN vs. "C") on the LFK benchmark on RISC machines.
burley@pogo.ai.mit.edu (Craig Burley) (12/19/90)
In article <15180@ogicse.ogi.edu> borasky@ogicse.ogi.edu (M. Edward Borasky) writes: In article <1990Dec19.032301.4449@murdoch.acc.Virginia.EDU> gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) writes: >Anyone volunteer to run SPEC through f2c and report times for Fortran >and C on a variety of boxes? Dumb idea! There are a number of factors that need to be isolated: 1. How efficient is the "C" code that f2c produces? 2. How efficient is the machine code that the target "C" and FORTRAN compilers produce? 3. How well-suited is the code to the architecture of the boxes in the first place, etc. Hey, there are NO dumb ideas! (Tag line left to the reader... :-) Seriously, I agree that f2c is probably not the best thing to compare to C, due to the following: 1. One of the reasons C can be slower than Fortran (and the other way around) is due to differing language semantics -- basically, different things they permit and deny to the programmer without providing a standard means for communicating exceptions. The common ones cited are that Fortran disallows aliasing among dummy arguments and entitities in common, which means that when compiling an individual program unit (procedure), if a compiler can't prove a given alias exists (via EQUIVALENCE), then it is able to assume one doesn't; and that C disallows automatic array reshaping across procedure calls, so it can and does implement multiple-dimension arrays as "layers" of indirection through pointers, whereas Fortran must usually use multiplication. Whether any of these differences result in an improvement for a given program, compiler, and/or machine, is beside the point. 2. f2c is (presumably) translating standard Fortran into standard C, and it does so on a procedure-by-procedure basis, not via global optimization. 3. A straightforward translation of Fortran into C is going to lose most of the semantic advantages of Fortran while still, most likely, preserving its disadvantages; comparing the result to a program written originally in C is likely to be unfair, because the C version probably won't incorporate any of the disadvantages imposed by Fortran. However, there is no reason not to do the experiment if someone wants, because (another numbered list): 1. The results will be valuable for those who really only have a choice between C and f2c (presumably for new programs). As long as nobody misrepresents the results as indicating which language is better, but simply whether using Fortran as a high**2-level language (on top of C, which is arguably a high**1-level language) is about as effective as using C. The difference is somewhat like comparing the performance of C to that of an equivalent program written in native assembler: one would expect the higher level to be worse, but in some cases it might surprise you. 2. f2c apparently is the only free Fortran "compiler" for UNIX boxes. When GNU Fortran (gf77) comes out, it will be the second, and it will be very helpful to have benchmarks for f2c against which gf77 can be compared. Initially it might well have worse performance than f2c (though I doubt it), but observing the improvements it makes over a (possibly but not necessarily static) f2c will be helpful. There are issues other than this. For example, one must consider whether ones wants a raw, low-level, pedal-to-the-metal comparison, in which case one must write "equivalent" programs in both languages that are both highly hand-optimized (within the language, perhaps standard and "portable", but where the optimizations might assume a given target machine -- the same one for both the C and Fortran versions, of course), or a direct comparison of "good, readable" code in both languages. The former is useful if you really don't care much which language to use, but you do want to achieve the highest performance possible within that language by tinkering. The latter is useful if you want to express your program is whatever is a natural, readable, and maintainable way, and get the most performance without hand-optimizing except at the algorithmic level (whatever that is). And, in the latter case, you might well consider in which language your application will be more naturally expressed along with any benchmark results -- for example, lots of complex arithmetic? use Fortran; lots of complicated data structures? use C. Ok, maybe there's no such thing as a bad benchmark -- just a bad explanation of what the benchmark actually means! -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
borasky@ogicse.ogi.edu (M. Edward Borasky) (12/19/90)
As a side note, it has only been since Convex introduced their vector- izing C compiler that the debate over C vs. FORTRAN for numerical work had ANY valid reason for answering "C". And only the introduction of RISC architectures in the commercial market has given "C" any status as a numerical application language. But I agree with you that f2c- produce C code is likely to be inferior to hand-produced C code. In my original posting I recommended the Livermore FORTRAN Kernel benchmark as a test of C vs. FORTRAN; I think the SPEC test with FORTRAN code pushed through f2c is a waste of time (but then I think f2c is a waste of time, too).
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (12/20/90)
In article <15180@ogicse.ogi.edu> borasky@ogicse.ogi.edu (M. Edward Borasky) writes: >>Anyone volunteer to run SPEC through f2c and report times for Fortran >>and C on a variety of boxes? >Dumb idea! There are a number of factors that need to be isolated: Bzzt. I did not claim I could isolate the factors -- I just want to see, in general, what the total factor (f2c + relative fortran/cc compiler + inherant fortran superiority) is. With any benchmark like this, all you have to do is remember what you're measuring. Since no numbers of this sort exist yet, I think SPEC would make a great first try. On to your issues: >1. How efficient is the "C" code that f2c produces? To eye, it looks good. >2. How efficient is the machine code that the target "C" and FORTRAN >compilers produce? This will be tested. I would like to know if a particular vendor's FORTRAN or C is relatively poor. The vendor might want to know if he could use f2c to get a faster SPECmark ;-) >3. How well-suited is the code to the architecture of the boxes in the >first place, etc. This I understand, I think. Interpreting SPEC always requires some thought as to what sorts of operations the benchmark does. No new issue there. >As a first cut, the Livermore FORTRAN Kernels (LFK) benchmark is >available in both FORTRAN and C. The C translation was hand-coded >with loving care by Greg Astfalk (then of AT&T, now of Convex.) It is >NOT repeat NOT a coincidence that [...] I want to test a variety of codes, mainly to find out if my guess (that aliasing information is important) is true. Finding that one particular benchmark (LFK) is comparable in speed is not interesting to me. I'd be very interested at seeing what's comparable and what's not. > I would expect similar speeds (FORTRAN vs. "C") on >the LFK benchmark on RISC machines. I'd like to see all of SPEC, so we're more likely to be surprised.
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (12/20/90)
In article <BURLEY.90Dec19074504@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes: > 3. A straightforward translation of Fortran into C is going to lose > most of the semantic advantages of Fortran while still, most likely, > preserving its disadvantages; comparing the result to a program > written originally in C is likely to be unfair, because the C > version probably won't incorporate any of the disadvantages imposed > by Fortran. The thing that I was out to test was NOT codes that could take advantage of C, but codes which were ideally suited to Fortran. I could bore you with details, but I think several of the SPECmark programs fall nicely into this category. When I get back from break I'm going to run my hydrocode through f2c; I can assure you that to the best of my (limited ;-) knowledge, there's no faster way to do the algorithms in C.
raveling@Unify.com (Paul Raveling) (12/21/90)
In article <1990Dec19.032301.4449@murdoch.acc.Virginia.EDU>, gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) writes: > There has been an ongoing debate for umpteen years about whether > Fortran or C is more appropriate for modern numerical programs. ... > > Anyone volunteer to run SPEC through f2c and report times for Fortran > and C on a variety of boxes? In comparing the same benchmark in different languages be careful about whether the language or the compiler is the factor that accounts for speed differences. A year or 2 ago I tried dhrystone in its Fortran version and its C version on an HP 9000/350 (maybe 370 by that time). For the C version, I tried versions compiled by the HP C compiler and GCC. Subject to the usual disclaimer of possibly foggy memory, my recollection is that the result were like this: Fastest: C compiled by HP C compiler 2nd: FORTRAN compiled by HP FORTRAN compiler Slowest: C compiled by gcc Yes, both C compilers were fed identically the same source. ------------------ Paul Raveling Raveling@Unify.com