Related articles |
---|
Wanted: folk theorems in Fortran Programming. steve@hubcap.clemson.edu (1993-01-26) |
Re: Wanted: folk theorems in Fortran Programming. dodd@mycenae.cchem.berkeley.edu (1993-01-27) |
Re: Wanted: folk theorems in Fortran Programming. apofort!metcalf@dxmint.cern.ch (1993-01-28) |
Re: Wanted: folk theorems in Fortran Programming. davidm@questor.rational.com (1993-01-28) |
Re: Wanted: folk theorems in Fortran Programming. davidm@questor.rational.com (1993-01-28) |
Re: Wanted: folk theorems in Fortran Programming. steve@hubcap.clemson.edu (1993-01-29) |
Re: Wanted: folk theorems in Fortran Programming. wand@dec5120z.ccs.northeastern.edu (1993-01-29) |
Newsgroups: | comp.compilers,comp.lang.fortran |
From: | davidm@questor.rational.com (David Moore) |
Keywords: | Fortran, optimize |
Organization: | Rational |
References: | 93-01-193 |
Date: | Thu, 28 Jan 1993 20:14:21 GMT |
steve@hubcap.clemson.edu ("Steve" Stevenson) writes:
>I am trying to make a catalog of folk wisdom in fortran programming. I
>already have a some theorems. For example:
> BAD GOOD
>x = y/2.0 x=y*0.5
>a**5 (a*a)*(a*a)*a
>2.0*x x+x
Do these qualify as "old chestnuts"? I happen to think that the "BAD"
forms are in fact the way each of these should be coded if your objective
is to produce fast code from an optimizing compiler.
The point is that any decent optimizing compiler is going to recognize all
of these "bad" forms and convert them into something better. It is much
less likely that the compiler will recognize the "GOOD" forms.
A good example of when the "GOOD" form is actually bad occurs in C. Old
hands will write:
float a,b[100],c[100];
float *pb,*pc;
int i;
a=0.0;pb=b;pc=c;
for (i=0;i++;i<100) a+=(*pb++)*(*pc++); (i)
Which runs much better on a non-optimizing compiler than the simple:
for (i=0;i++;i<100)a+=pb[i]*pc[i]; (ii)
but which is much harder for an optimizing compiler to optimize than (ii).
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.