[J3] [EXTERNAL] Questions about DO CONCURRENT and locality
Ondřej Čertík
ondrej at certik.us
Mon Jul 6 11:48:00 EDT 2020
Hi Bill and others,
On Mon, Jul 6, 2020, at 7:09 AM, Bill Long via J3 wrote:
> DEFAULT(NONE) is a safety / programming style issue, sort of like
> IMPLICIT NONE. It helps catch typo issues in the loop, but I don’t
> think it is ever required for program correctness or making it possible
> for the compiler to figure out what is going on. The idea of
> specifically declaring “problem” variables in a SHARED, LOCAL, or
> LOCAL_INIT specifier should be sufficient.
Thanks for discussing this.
There still seems to be a problem. If you take the original code from the link in Steve's email: https://j3-fortran.org/doc/year/19/19-134.txt, which I am going to copy here for clarity:
SUBROUTINE FOO(N, A, B, T, K, L)
IMPLICIT NONE
INTEGER, INTENT(IN) :: N, K(N), L(N)
REAL, INTENT(IN) :: A(N)
REAL, INTENT(OUT) :: B(N)
REAL, INTENT(INOUT) :: T(N)
INTEGER :: J
DO CONCURRENT (J=1:N)
T(K(J)) = A(J)
B(J) = T(L(J))
END DO
END SUBROUTINE FOO
This can be parallelized efficiently for any of the following cases:
1. K=[1,2,3]; L=[4.5,6]
2. K=[1,2,3]; L=[1,5,6]
3. K=[1,2,3]; L=[1,2,3]
However, the parallel order will break the logic of the code for the following cases (the loop can be executed in any order, but if it is executed in parallel, the same element of T will be overwritten in parallel with different values and thus provide an incorrect answer), which should be invalidated:
4. K=[1,1,2]; L=[1,1,2]
5. K=[1,1,1]; L=[1,1,1]
You cannot currently do that with the shared, local, ... specifiers, because above you need to specify conditions on the elements of the arrays, not arrays as a whole.
I propose that users expect that if they write "do concurrent", they are telling the compiler that they are guaranteeing from the nature of the application problem that it can actually by executed in parallel (concurrently). Specifically in the case above they are guaranteeing that the content of the arrays K and L will be of the form 1., 2., or 3., and never of the form 4. and 5. Users can provide this guarantee, but compilers cannot figure this out.
See this issue for more discussion and background: https://github.com/j3-fortran/fortran_proposals/issues/62
Ondrej
More information about the J3
mailing list