This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forall vs OpenMP


On 04/08/2012 11:10 AM, Thomas Koenig wrote:
Hi Anton,

I tried to find any generic
guidelines regarding when
forall is preferable to OpenMP
parallelisation for simple
loops, but couldn't find any.

For gfortran, the general guideline is to avoid forall. It does not parallelize on its own. It is likely not to be any better than the equivalent DO loop, and sometimes it is much worse.

Regards

Thomas
One of the more easily understood but seldom mentioned aspects of forall is its sequential assignment definition, which is at odds with the DO (including DO CONCURRENT):
forall......
A=B
C=D
end forall
has the same meaning as
forall() A=B
forall() C=D
so a heavy load is placed on the compiler to optimize multiple assignments under forall.
DO CONCURRENT (or old-fashioned DO loops) don't place such a requirement. Even compilers which fuse loops more aggressively than gfortran have difficulty with this.
Nonetheless, in my examples, gfortran may perform better than ifort or open64 in cases of forall with multiple assignments. Of the compilers I test from time to time, only the Oracle compiler out-performs gfortran on such FORALL cases.
So, you may consider it a design limitation of FORALL under the standard.
I have the impression that inclusion of HPF features in f95 was done to avoid the threat of a forking of Fortran. In that respect, it seems to have been successful. It was not so successful in terms of adding syntax features which can be counted on to optimize performance across a range of compilers.
We have digressed from the original question.


--
Tim Prince


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]