[J3] [EXTERNAL] Questions about DO CONCURRENT and locality
Ondřej Čertík
ondrej at certik.us
Mon Jul 6 12:31:13 EDT 2020
Hi Tom,
On Mon, Jul 6, 2020, at 10:15 AM, Clune, Thomas L. (GSFC-6101) wrote:
>
> Hi Ondrej,
>
> If I understand correctly, merely “guaranteeing” that the loop can be
> parallelized in insufficient. The compiler needs to “know” whether to
> treat any given variable as SHARED or LOCAL. Small modifications of the
> example here can result in a different requirement in that regard to
> allow correct parallelization.
>
> In this example the user could specify SHARED(A,B,T,K,L) which would
> enable parallelization. (But would do unspeakable things if provided
> the data from your cases 4 & 5.)
>
> I’m not sure what more you can be asking for. The compilers cannot
> determine the proper locality at compile time due to insufficient
> information, and cannot do so _efficiently_ at run time. Additional
> information must be provided by the programmer.
I agree with this assessment, and I think the original proposal:
https://j3-fortran.org/doc/year/19/19-134.txt
that we are discussing here is trying to ensure that is the case in the standard itself. The proposal says:
"A processor implementing a parallel execution model of this construct
with the semantics required by the text of the Fortran 2018 standard
must capture the value of A(J) and substitute that value for T(L(J))
conditionally when K(J)==L(J). When there are multiple references to
and definitions of elements of T, the number of these conditional
forwardings grows as the product of the number of references and
definitions. The induced overhead reduces the efficacy of parallel
execution."
Which seems to suggest that the standard is currently requiring the compiler to do runtime checks, and as you said and I agree, this cannot be done efficiently at runtime.
The proposal is then suggesting a simple edit to the standard to resolve the issue.
I didn't the proposal, so I hope I understood it correctly.
Ondrej
More information about the J3
mailing list