Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!gatech!purdue!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Array Notation
Message-ID: <10249@lanl.gov>
Date: 4 Jan 91 00:17:35 GMT
References: <1991Jan03.163532.22692@convex.com>
Distribution: comp.lang.fortran
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 52

From article <1991Jan03.163532.22692@convex.com>, by psmith@convex.com (Presley Smith):
> [...]
> Using array syntax:
> 
>                 THE NAS KERNEL BENCHMARK PROGRAM
> [...]
>  TOTAL        1.0082E+00     2.1725E+09     34.1810       63.56
> 
> 
> And using plain vanilla fortran 77:
> [...]
>  TOTAL        1.9305E-10     2.1725E+09     21.8563       99.40
> [...]
> The MFLOPS definitely decrease for this code when the DO loops
> are expressed in the array section syntax.  We have smart users;
> They HATE to go slower.  So few apparently use the array
> syntax here at NAS, unless they want a code that can be run
> with minimal changes on the CM.

This is obviously an implementation problem - NOT a problem inherent
to the idea of using array syntax.  Since the product you were testing
was a preprocessor, I suspect that the compiler couldn't recover enough
of the information that the preprocessor filtered out.  (This is often
a problem with preprocessing.)  For example, consider the following
Fortran-Extended code fragment:

      real a(10), b(10), c(10), d(10)
      ...
      a = b
      c = d
      ...

If the preprocessor converts the two array assignments to separate
do loops, then the compiler may not see that the following code is
equivalent:

      real a(10), b(10), c(10), d(10)
      ...
      do 10 i=1,10
	 a(i) = b(i)
	 c(i) = d(i)
  10  continue

That is, the two loops can be combined.  CFT77, for example, cannot do
this.  Even so, it is clear that a compiler _could_ find this optimization
(and, given the original source rather than a preprocessed version, it
would probably be easier).  So, you shouldn't condemn a language feature
because of a single bad implementation.  (On the other hand, if you have
specific reasons that you think array syntax will be _inherently_ slower
regardless of compiler cleverness - speak up!)

J. Giles