FORALLs and /Qparalell

[Greynolds__Alan]

Does IVF parallelize all FORALL statements/blockswith the/Qparallel option? If not, shouldn't it be able to since by definition the iterations of a FORALL are independent and reference onlyPURE functions with no side-effects?

Al Greynolds
www.ruda-cardinal.com

[Steven_L_Intel1]

No - the semantics of FORALL end up making it very difficult to parallelize. This is why Fortran 2008 added DO CONCURRENT, which is "FORALL done right". I will note that FORALL is not a loop, so talking about iterations can be confusing. It is effectively an array assignment.

[Greynolds__Alan]

Thanks for the tip Steve. I just read John Reid's discussion of FORALL versus DO CONCURRENT inftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1729.pdf Does this mean that IVF will parallelize all DO CONCURRENT blocks if I switch from FORALLs?

Al

[Steven_L_Intel1]

Intel Fortran 11.1 doesn't support DO CONCURRENT. Support will be added in a future release. The compiler will attempt to parallelize DO CONCURRENT constructs if you use /Qparallel - there's no guarantee of parallelization, but the odds are good.

[j_clausen]

SoFORALL is pretty much obsolete, then?

j_clausen

[Steven_L_Intel1]

In my opinion, yes.

[j_clausen]

Quoting Steve Lionel (Intel)

No - the semantics of FORALL end up making it very difficult to parallelize. This is why Fortran 2008 added DO CONCURRENT, which is "FORALL done right". I will note that FORALL is not a loop, so talking about iterations can be confusing. It is effectively an array assignment.

Why must the "DO CONCURRENT" be invented? Couldn't Intel just change the way FORALL is implemented and make that the "FORALL done right"?

It maybe a dumb question with an obvious answer, but bear with me, a mere civil engineer and occasionalIVF user :-)

j_clausen

[TimP]

The limited step which ifort has taken which may correspond with your suggestion is the facility to optimize FORALL in certain contexts with !DIR$ IVDEP. Changing the meaning of standard syntax, even under a compiler option, has continually proven unsatisfactory. No doubt, the standards committee wrestled with this question, and decided a new keyword would be the better solution.

[Steven_L_Intel1]

It's not a question of "implementation", but rather, as Tim says, of semantics. We can't change the meaning of a program that uses FORALL just because it doesn't parallelize well.