[J3] Questions about DO CONCURRENT and locality

Fri Jul 3 17:49:07 EDT 2020

Bill is right. If users specify DEFAULT(NONE), they are required to specify
locality for each variable that
appears in the DO CONCURRENT construct.

As long as all the variables that appears in the DO CONCURRENT construct
have explicit locality,
the processor doesn't need to exhaust the algorithm to figure out which one
is shared/local,
there is no problem with parallelisation and extra impact to the
performance.
Otherwise, the original problem remains.

Daniel

XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran

From:	Bill Long via J3 <j3 at mailman.j3-fortran.org>
To:	General J3 interest list <j3 at mailman.j3-fortran.org>
Cc:	Bill Long <longb at cray.com>
Date:	2020-07-03 04:41 PM
Subject:	[EXTERNAL] Re: [J3] Questions about DO CONCURRENT and locality
Sent by:	"J3" <j3-bounces at mailman.j3-fortran.org>

> On Jul 3, 2020, at 2:59 PM, Daniel C Chen via J3
<j3 at mailman.j3-fortran.org> wrote:
>
> This is a known issue that was first discussed in
https://urldefense.proofpoint.com/v2/url?u=https-3A__j3-2Dfortran.org_doc_year_15_15-2D150.txt&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=57cafTO2T1scnwZfrlLPsghkmjFH2AuUtlcWE5nRktg&m=8l3XKH6JIER7dH85NLDUZEs_k_N77h-CgbRE76ZXqgc&s=l0fDsx4PDVo7HJzBW43_pslz0Tl2ao-NqkKoe0bwx2s&e=

> The problem is that the wording in F2008 makes it almost impossible for
the processor to
> determine if an entity that appears in a DO CONCURRENT construct is
shared or local.
> I said "almost" because there is a way to implement it that requires a
lot of
> book keeping and copy-in/copy-out, which pretty much destroy the
performance
> this feature is supposed to bring.

Right.  The main problem comes when a variable definition is protected by a
condition, usually an IF statement.  It is difficult to tell whether this
constitutes a previous definition before a subsequent reference outside the
IF construct. But the 2008 rules, determination of local versus shared
depended on such ordering of definition/reference.  This is part of why we
have locality specs now.   The F2008 implementation was substantially
complicated because of this.
>
> This finding is also the reason we added localities for DO CONCURRENT in
F2018 to
> allow users to specify the locality by themselves.
> However, due to the concerns of backward compatibility, F2018 didn't add
"default"
> locality even though it was requested at the time.
> As the result, there is still a hole in the standard that makes
> determination of a SHARED variable very difficult. It will completely
kill the performance
> if a processor has to implement it).

If I recall the discussion, allowing DEFAULT(SHARED) would basically force
the user to declare all of the local  variables as LOCAL or LOCAL_INIT to
have the loop make logical sense.   Similarly for DEFAULT(LOCAL). Providing
only DEFAULT(NONE) as a mechanism for requiring declaration of ALL the
variables seemed less error-prone.  (OpenMP does allow DEFAULT(SHARED) and
includes a long list of reasons that cause a variable to be automatically
private.  Which is probably broken.)

Cheers,
Bill

>
> Daniel
>
> XL Fortran Development, Fortran Standard Representative
> IBM Toronto Software Lab
> Phone: 905-413-3056
> Tie: 969-3056
> Email: cdchen at ca.ibm.com
> http://www.ibm.com/software/awdtools/fortran/xlfortran
>
> <graycol.gif>Steve Lionel via J3 ---2020-07-03 03:31:48 PM---In
https://urldefense.proofpoint.com/v2/url?u=https-3A__j3-2Dfortran.org_doc_year_19_19-2D134.txt&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=57cafTO2T1scnwZfrlLPsghkmjFH2AuUtlcWE5nRktg&m=8l3XKH6JIER7dH85NLDUZEs_k_N77h-CgbRE76ZXqgc&s=OJEx2A0kXKJZqEHSPEIlCDPSMo6KrNcuBIfjYtKn_Tw&e=

>
> From: Steve Lionel via J3 <j3 at mailman.j3-fortran.org>
> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
> Cc: Steve Lionel <steve at stevelionel.com>
> Date: 2020-07-03 03:31 PM
> Subject: [EXTERNAL] [J3] Questions about DO CONCURRENT and locality
> Sent by: "J3" <j3-bounces at mailman.j3-fortran.org>
>
>
>
>
> In
https://urldefense.proofpoint.com/v2/url?u=https-3A__j3-2Dfortran.org_doc_year_19_19-2D134.txt&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=57cafTO2T1scnwZfrlLPsghkmjFH2AuUtlcWE5nRktg&m=8l3XKH6JIER7dH85NLDUZEs_k_N77h-CgbRE76ZXqgc&s=OJEx2A0kXKJZqEHSPEIlCDPSMo6KrNcuBIfjYtKn_Tw&e=
   Peter Klausler asked
> whether the words in the standard actually enabled parallelization of DO
> CONCURRENT. I see that the paper was not taken up at 218 but I wasn't
> aware of any discussion of the topic then or at later meetings. It came
> up again today in discussions at the (online) FortranCon hosted by the
> University of Zurich (which has been great so far - almost over.)
>
> As I don't pretend to be a parallelization expert, I'd be interested in
> hearing others' thoughts on the issues Peter raised. Thanks.
>
> Steve
>
>
>
>

Bill Long
longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/
Bloomington, MN  55425

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200703/2d456ac1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200703/2d456ac1/attachment.gif>