Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!tank!ncar!mailrus!cornell!uw-beaver!microsoft!bobal
From: bobal@microsoft.UUCP (Bob Allison)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN 88
Message-ID: <1127@microsoft.UUCP>
Date: 28 Oct 88 15:00:41 GMT
Article-I.D.: microsof.1127
References: <5833@vdsvax.steinmetz.ge.com> <7540@megaron.arizona.edu> <74566@sun.uucp>
Reply-To: bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal))
Distribution: comp.lang.fortran
Organization: Microsoft Corp., Redmond WA
Lines: 44

In article <74566@sun.uucp> khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes:
>In article <7540@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:
>
>
>   Perhaps you would be more concerned if you weren't compiling on a
>   Cray-2?  One weakness of the standard (it seems to me) is that it seems
>   to be designed for extremely powerful machines.  A lot of FORTRAN code runs
>   on machines several orders of magnitude slower than a CRAY-2.  While the
>   difference between compilation times of 10 seconds and 100 seconds may
>   not be enough to worry about, the difference between 2 minutes and 20
>   minutes --- the same factor of 10 --- is the difference between a
>   quick stretch and a long coffee break.
>
>Most of the time spent in such a compiler is the optimizer. If you
>don't have a fancy vector processor and a complex set of related
>functional units, compilation goes very quickly.
>
>The difference between 2 minutes and 2minutes 45 seconds may feel like
>forever, but with f88 you might not need such big source files.
>Keith H. Bierman
>It's Not My Fault ---- I Voted for Bill & Opus

Ah, but this is precisely the problem: on a small scalar machine, an
optimization phase is just as time-intensive as on a Cray, but the array
language reduces the amount of optimization necessary on a Cray (well,
a little) and greatly increases the amount of optimization necessary on
a scalar machine.  

"If you don't have ... a complex sex of related functional units": this
is the same guy who couldn't understand why anyone was against MODULEs,
I believe (if not, accept my apologies; but the point is still valid).

Also, run-time performance will necessarily decrease, since I can't figure
out how to do compile-time analysis of an array statement such as:

A = RESHAPE(ESHAPE(A),TRANSPOSE(SPREAD(B,3,I)))

(Complete nonsense, but it makes the point that at compile time I have
no idea what the size of intermediate array expressions will be).  So, while
I am in favor of the concept of array operations, I want people to realize
it will not be a freebie, and I want to try to reduce the possibility of
statements like the above popping up.

Bob Allison