(j3.2006) (SC22WG5.4023) Late in the day question
Andy Vaught
andyv
Thu Jun 25 03:20:00 EDT 2009
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
More information about the J3
mailing list