Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!snorkelwacker.mit.edu!ai-lab!life!burley
From: burley@pogo.ai.mit.edu (Craig Burley)
Newsgroups: comp.benchmarks
Subject: Re: Anyone volunteer to do Fortran vs. C on SPECmarks?
Message-ID: <BURLEY.90Dec19074504@pogo.ai.mit.edu>
Date: 19 Dec 90 12:45:04 GMT
References: <1990Dec11.163826.5439@eagle.lerc.nasa.gov>
	<1990Dec15.094523.10622@groucho> <111621@convex.convex.com>
	<1990Dec19.032301.4449@murdoch.acc.Virginia.EDU> <15180@ogicse.ogi.edu>
Sender: news@ai.mit.edu
Organization: /home/fsf/burley/.organization
Lines: 87
In-reply-to: borasky@ogicse.ogi.edu's message of 19 Dec 90 05:41:42 GMT

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