fouts@orville.nas.nasa.gov (Marty Fouts) (03/30/88)
Gene was right to redirect the Fortran Horror discussion to comp.lang.fortran, but before we leave the subject completely, there is one aspect that I would like to bring up in an architectural setting. Several of the pro-Fortran letters have made claims that other languages are not as efficent as Fortran for numerical applications, even alluding to C as a poor choice. My experience has been quite different. A while back, I obtained the Fortran source for the Livermore Loops, and transliterated (not translated) them into C. I ran these loops on several machines and discovered something interesting: On the machines where the vendors cared the most about their C compiler, the C versions ran faster. On the machines where the vendors didn't care, the Fortran versions ran faster. In particular, the Convex ran all of the C loops faster than the Fortran loops, while the Cray 2 ran most of the Fortran loops faster than the C loops. In fact, the Convex C compiler found a loop optimization in one of the C loops that none of the other (Fortran or C) compilers discovered. From an architectural point of view, my point is this: How well a given language does on a given machine depends more on how much work the compiler writers put out for that language on that machine than on many other factors. As others here have pointed out in the past, a good working relationship between the instruction set designers and the compiler writers can lead to an architecture which eases the compiler writers job, allowing them to get much more benefit from the machine. However, within a certain class of languages (algebraic, procedural) which includes Fortran, C, Pascal and some others, it is pretty much possible to get nearly the same performance out of any language; provided you keep the problem domain small enough. (For the pendant: Translitteration means that I kept to the Fortran semantics as closely as possible, even in those cases where a different approach would have been "more natural" to a C programmer. The point of the experiment was to demonstrate that you could in fact (at least for numerical calculations) write Fortran in C. The only problem I had was in converting 1 based array references to 0 based array references, but I overcame this.) I am not trying to say here that C is a better language than Fortran, but rather that procedural languages are all pretty much similar, and the same kind of problem tends to get expressed the same way in each. We are better served by saying our languages have these properties than by saying my language is better than yours -- and then going on to figure out how best to generate code for these languages. I am also not trying to say that C doesn't have constructs that are hard to optimize or that Fortran doesn't; I am only saying that if efficency is important, than programmers tend to use the constructs which are easiest to optimize.