(j3.2006) (SC22WG5.4023) Late in the day question

[Andy Vaught]

yOn Wed, 24 Jun 2009, Robert Corbett wrote:

> Andy Vaught wrote:
> 
> > On Tue, 23 Jun 2009 dick.hendrickson at att.net wrote:
> > 
> > 
> >>It's my belief that FORALL was a mistake.  Before a processor can
> >>efficiently optimize a general FORALL construct it must prove a
> >>bunch of theorems about left-to-right and line-to-line independence
> >>and the theorems are almost identical to the ones it would have to 
> >>prove in order to vectorize a loop.  
> > 
> > 
> >   ... and in the case that it can't, compiler-generated temporaries are
> > required.  Yuck.  Making FORALL conceptually simple ended up making it
> > almost worthless.  Concurrent do is much better, even though it requires
> > more care to use.
> 
> I don't know what you mean by the phrase "making FORALL conceptually
> simple."  I do not recall having before seen anyone assert that FORALL
> construct is conceptually simple.  In any case, the FORALL construct in
> Fortran 95 and FORTRAN 2003 is largely the same as that of HPF 2.0.
> What do you think the designers of HPF should have done differently to
> make FORALL worthwhile?
> 
> In my work at Sun, I have had to explain what FORALL does to many users.
> A lot of them thought that FORALL was a parallel DO.

  I meant the requirement that it is a loop-like construct in which the
body statements act as if all the iterations happen at the same time--
each 'iteration' is independent of the others.  Simpler, in a sense, than
a real loop.  The reality is that one set of dependencies was traded for
another, with less than optimal results.

    Andy