Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!hc!beta!a!jlg
From: jlg@a.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN horrors (character init)
Message-ID: <594@a.UUCP>
Date: 27 Apr 88 07:10:01 GMT
References: <563@a.UUCP> <6690016@hpclcdb.HP.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 34
Summary: array speed

In article <6690016@hpclcdb.HP.COM>, cdb@hpclcdb.HP.COM (Carl Burch) writes:
> > > >so the compiler is going to be substantially bigger just from that effect
> > > >alone (not counting the increase in size due to more language features).
> > 
> > Why does a larger run-time library cause the compiler to be bigger?  Surely
> > 
> > > features, will execute slower than before (for instance, the array stuff
> > > vs. DO loops).
> > >
> > The array manipulation stuff in Fortran 8x should be UNIFORMLY faster than
> > the equivalent DO loops.  
> 
> It looks like Mr. Giles is assuming shared libraries and sophisticated

Not at all.  Consider the following:
        A=B+C
where A, B, and C are conformable 3-D arrays.  The equivalent loops are:
      DO I=1,N
         DO J=1,M
            DO K=1,L
               A(I,J,K)=B(I,J,K)+C(I,J,K)
            END DO
         END DO
      END DO
The inner loop setup is done M*N times and the J loop setup is done N
times.  In the 8x version, the compiler is free to choose the order in
which the calculation is done (the compiler COULD rearrange the loops in
the Fortran 77 version - but only a SMART compiler will be able to figure
whether it's safe).  In fact, the 8x version is free to notice that A, B,
and C are contiguous (not RANGEs, for example) and the 8x compiler can do
the statement as a single loop (or vector instruction if you have them).
Even on the MS-DOS machines this saves M*(N+1)-1 loop setups!

J. Giles
Los Alamos