Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!jarthur!elroy.jpl.nasa.gov!ames!pacbell!att!cbnewsc!res
From: res@cbnewsc.ATT.COM (Rich Strebendt)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Summary: Another perspective
Message-ID: <12950@cbnewsc.ATT.COM>
Date: 19 Jan 90 00:49:26 GMT
References: <15623@haddock.ima.isc.com> <8960003@hpfcso.HP.COM> <1990Jan17.042608.447@esegue.segue.boston.ma.us>
Organization: AT&T Bell Laboratories
Lines: 43

In article <1990Jan17.042608.447@esegue.segue.boston.ma.us>, johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
> In article <8960003@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes:
> >If you limited Fortran math optimizations to deal only with those
> >functions actually specified by Fortran 77, you'd probably be on a par with
> >C.
> 
> The Fortran 77 standard allows an implementation to have as many intrinsics
> as desired.  Functions can be expanded in-line, moved out of loops, and
> otherwise optimized, unless you specifically declare them external to tell it
> to use one that you wrote in preference to any external.
> 
> Fortran very specifically prohibits invisible aliasing among arguments and
> common, the optimizer is allowed to make the most optimistic assumptions in
> this case.  

It seems that this discussion has gotten to the "my optimizer is
bigger than your optimizer" stage.  Allow me to address this topic
from another perspective.

I prefer to write code in C (though I have also spent many years
writing in FORTRAN) because it allows me to better describe my INTENT
to the compiler and let it generate code that needs LESS optimization.
For example, I expect the compiler to generate cleaner code for a
structure copy than for an element-by-element copy of that structure,
perhaps using block move capabilities in the hardware.  Similarly,
using the x += y construct instead of X=X+Y will be a winner for the
compiler (especially if x is a multidimensional array) and will
require no pattern matching abilities in the optimizer to detect --
the optimizer will not even see the second construct in the compiler's
output.  There are a number of other examples that could be given
(such as incrementing a pointer rather than incrementing an index for
an array then recomputing the address of the array element), but
perhaps these will suffice to make my point.

In considering the final result, one should not ignore information
that the programmer can supply as clues to the compiler and optimizer
to obtain a better result.  Also, it should also be kept in mind that,
while it is fun to figure out how to optimize very exotic constructs,
the most frequently occuring construct in any programming language is
equivalent to the construct x += 1

					Rich Strebendt
					...!att!ihlpb!res