(j3.2006) (SC22WG5.5931) Comments on some of the comments
Fri Aug 11 11:39:07 EDT 2017
Each image has its own instance of a declared team variable (as it the case for any variable). As John and the TS noted, the idea that team variable values would be different among the images of a team was part of the design all along. There are a couple of basic reasons for this.
1) The FORM TEAM statement is how team variables are normally defined (apart from copying the value via assignment of an already-defined team variable). All the team-related information is returned to the program via the team variable specified in the FORM TEAM statement. That includes, for example, the index of the image in the new team. Different value for each image (one hopes). Other information that would be computed by FORM TEAM, such as the identities of the images above and below the executing image in a reduction tree, are also image-specifiec. Pretty much the only team information items that are the same are the number of images in the team, the team number, and the pointer to the parent team.
2) It would conceivable to put the information for all the images in the team into each team variable. There would still be the problem of identifying the index of the local image, but the real problem is that this scheme scales horribly for large numbers of images. Just not practical.
> On Aug 11, 2017, at 4:42 AM, John Reid <John.Reid at stfc.ac.uk> wrote:
> Malcolm Cohen wrote:
>> John Reid writes:
>>> An underlying assumption of HPC has always been that the team values on
>>> the images of a team would differ from image to image.
>> Sorry, but I cannot agree with this. Where has coarray TS said anything
>> that might imply this? I see nowhere, and the technical effect of what it
>> does state implies the opposite!
> See the last sentence of 5.1, para 1: "Information about the team to
> which the current image belongs can be determined by the processor from
> the collective value of the team variables on the images of the team."
> According to the TS, this should have been copied to 2.3.4, now 5.2.4,
> but it seems to have disappeared.
> Yes, we have goofed in not making the intention clearer.
> Best wishes,
>> It might have been in some people's minds, but it is counter to various
>> things I have heard other people involved in HPC say. Perhaps they were all
>> mistaken, but...
>> Moreover, it would have been very easy (trivial in fact) to make a team
>> variable "differ from image to image", BUT THIS WAS NEVER DONE. According
>> to the coarray TS and the draft standard you can assign team variables from
>> one image to another AND THIS DOES NOT CHANGE THE VALUE, so it still
>> identifies the same team.
>> Such a fundamental upheaval in the model is simply unacceptable. Those who
>> have already started to implement teams according to the coarray TS, as
>> modified by the tweaks we have made later, are going to be very annoyed they
>> have to restart their design.
>> If you are serious, in my opinion this mean you should be voting NO on the
>> CD and going back to the beginning. Oh, and stop calling it Fortran 2015 as
>> this is a fundamental change. Fortran 2017 (assuming we can actually reach
>> agreement this year!) is what it should be.
>> I cannot believe that we are revisiting fundamental design issues years
>> after publication of the TS and when we are supposedly so far advanced in
>> standardising F2015.
>>> This what the changes aim to ensure.
>> Right, that you can no longer use GET_TEAM fully is merely collateral
>> damage. Words like "you can not be serious" spring ineluctably to mind.
>> Yours in despair,
> J3 mailing list
> J3 at mailman.j3-fortran.org
Bill Long longb at cray.com
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
More information about the J3