Re: forall and do loop

highegg wrote:
On Jul 27, 6:31 pm, *** Hendrickson <***.hendrick...@xxxxxxx> wrote:
aeroguy wrote:
Thanks guys. Ok so i don't want to manually modify my code for any
optimization? But then there are these two ways to do so...which one
should be followed. Both are correct ? right? Then how should i
determine which one i should use.... why i should give the first
preference or the latter one?
Is there a staright answer without going into compilers?
Yes, the straight answer is "Never use a FORALL unless you are sure
you have a specific processor dependent need for it."

That's again the premature optimization approach - why?

Not really premature optimization. FORALL was added in 1995 and was
essentially copied from the High Performance Fortran language. HPF
was aimed at the kind of multi-processors being built in the 80's and
early 90's. They thought FORALL mapped highly parallel code naturally
onto the hardware. 65,000 processors is different from a duel core
chip. If you're working on a highly parallel code for a multi-processor
complex, why not tell the compiler that you know things can be done in
parallel. The problem is that FORALL wasn't well enough specified to
allow the expected gains.

*** Hendrickson

It's not a
general looping concept.

No, it's not.

It was added to give some support for
some forms of multi-processors.

Yes, I've read somewhere that it was regarded as a sort of "parallel
DO" by many, even in the standardization committe.

Unfortunately, it has some "features"
that make it difficult for a compiler to optimize.

The whole array expressions stuff has this feature -
the code must behave as if the whole rhs is evaluated before
assignment. It's not bad, just different way of thinking.
For instance,
FORALL(i=j+1:n) a(i,j) = a(j,i)
and
DO i=j+1,n
a(i,j) = a(j,i)
END DO
are _equally_ difficult to optimize. In both cases, the compiler
is likely to fail to discover the independency. In the first case, it
will result in using a temporary array. In the latter case, it just
means that the loop will not be optimized (unrolled or whatever). The
speed impact of the former is usually worse.

Unless you have
a problem that maps well to multi-processors, DO loops will always
generate code that is at least as good as FORALL code for any useful
loop; they'll often do better.

Yes, this is again true for all array expressions and WHERE
assignment. But the DOs and IFs will frequently be less elegant and
understandable, and you have to make necessary temporaries on your
own.

.

Quantcast