[J3] [EXTERNAL] Questions about DO CONCURRENT and locality

[Bill Long]

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. 

Cheers,
Bill


> On Jul 6, 2020, at 7:13 AM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Does one actually have to resort to DEFAULT(…) to sidestep the concern?   Or is it sufficient to put the “problematic” variables into appropriate LOCAL/SHARED locality specs?       I.e, if most of the loop is all-but trivial, but one array is used with indices in a hard-to-predict manner, but that array is explicitly listed in SHARED(), does that give the compiler enough information to parallelize while the locality of other variables is left implicit?
> 
> 
> 
> 
> 
>> On Jul 3, 2020, at 9:54 PM, Daniel C Chen via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> I think the question of "CAN all DO CONCURRENT loops be parallelized" should be a
>> question for the vendors, not the standard committee as it is an implementation detail.
>> The standard does (should) not specify how a feature is implemented.
>> The processor can choose to implement it in parallel whenever it is possible or
>> sequentially as long as the result is the same (as Bob said). 
>> 
>> DEFAULT(NONE) will force users to specify
>> the locality of all variables that appear in a DO CONCURRENT construct. The 
>> processor should be able to parallelize the loops accordingly. That being said,
>> it would be users responsibility to specify the correct locality. For example, 
>> not marking a variable that is defined in two different iterations SHARED.
>> 
>> 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>"Ondřej Čertík via J3" ---2020-07-03 09:03:33 PM---Robert, On Fri, Jul 3, 2020, at 6:23 PM, Robert Corbett via J3 wrote:
>> 
>> From:  "Ondřej Čertík via J3" <j3 at mailman.j3-fortran.org>
>> To:  "J3 Mailinglist" <j3 at mailman.j3-fortran.org>
>> Cc:  "Ondřej Čertík" <ondrej at certik.us>
>> Date:  2020-07-03 09:03 PM
>> Subject:  [EXTERNAL] Re: [J3] Questions about DO CONCURRENT and locality
>> Sent by:  "J3" <j3-bounces at mailman.j3-fortran.org>
>> 
>> 
>> 
>> 
>> Robert,
>> 
>> On Fri, Jul 3, 2020, at 6:23 PM, Robert Corbett via J3 wrote:
>> > I am not sure of the question here.
>> > If the question is "can all DO
>> > CONCURRENT loops be
>> > parallelized?", the answer is
>> > clearly "no". The Fortran 2008
>> > and 2018 standards specify that
>> > the iterations of a DO
>> > CONCURRENT loop can be
>> > executed in any order. They do
>> > not specify that the
>> > executions of the iterations of
>> > a DO CONCURRENT loop can
>> > be intermingled. Each iteration
>> > is executed to completion
>> > before the next iteration begins.
>> 
>> Thanks a lot for this excellent clarification.
>> 
>> Not being a native speaker, my understanding of the word concurrent is either "occurring at the same time" or "parallel", as I just looked up here:
>> 
>> https://www.merriam-webster.com/dictionary/concurrent 
>> 
>> But according to the current interpretation of the standard, "do concurrent" doesn't specify concurrent execution. Is my understanding correct?
>> 
>> I would be in favor to change the standard to ensure "do concurrent" specifies concurrent execution. As expected by a lot of people as well as the meaning of the word.
>> 
>> Ondrej
> 

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