(j3.2006) Comments on some of the comments

John Reid John.Reid
Thu Aug 10 05:14:26 EDT 2017


Malcolm,

An underlying assumption of HPC has always been that the team values on 
the images of a team would differ from image to image. FORM TEAM would 
work collectively to construct values that would let each image access 
another image of the team efficiently. It is therefore important that 
when the value is referenced by an image, it is the value that was 
defined by that image. This what the changes aim to ensure.

No edit was suggested for CHANGE TEAM because [188:4-5] seems to imply 
what we want, but the wording probably does need to be tightened.

Cheers,

John.

Malcolm Cohen wrote:
> Hi Jon,
>
>
>
> CHANGE TEAM uses a team-value, not a team-variable.  And you can assign
> team-variables across images, so preventing CHANGE TEAM from using a
> coindexed variable would not solve anything for CHANGE TEAM (anyway I
> don?t see any edit to CHANGE TEAM here).
>
>
>
> Preventing FORM TEAM from writing to a coindexed variable does not solve
> anything either, as it can be assigned to a coarray on another image.  I
> stand by my comments on FORM TEAM: it might be unusual (weird or strange
> even), but it?s not obviously wrong to have a coindexed variable here.
> As it does not prevent misuse, merely make it microscopically harder to
> misuse, I don?t see the point in introducing a gratuitous incompatibility.
>
>
>
>>you could do a change team to a team variable that describes a team
> which the executing image is not a member of.  Do you think these things
> should be allowed?
>
>
>
> But these edits don?t achieve disallowing it.  The teams in image
> selectors are already required to be ancestor teams, which means the
> executing image has to be a member (otherwise it?s not an ancestor
> team); in SYNC TEAM the executing image is already explicitly stated to
> be required to be a member.  So those are already ok.
>
>
>
> CHANGE TEAM does not clearly state that the executing image has to be a
> member of the team identified by team-value, apart from it being an
> immediate consequence of ?current team for the statements of the CHANGE
> TEAM /block /is the team identified by the /team-value/?; if the
> executing image is not a member of that team, there is a direct
> contradiction, so by clause 4, that is not conforming.  We don?t like to
> rely on clause 4 for implicit requirements, so the wording in CHANGE
> TEAM should be improved to make that requirement explicit.  (Fiddling
> with FORM TEAM would just put a tiny (and avoidable) roadblock in the
> way, without actually making any explicit requirement on CHANGE TEAM.)
>
>
>
> So I think the edit you need is on [188:7], just after the text I quoted
> above, insert ?The executing image shall be a member of the team
> identified by /team-value/.?  Since this is already an implicit
> requirement of the immediately preceding sentence, it is an Editorial
> change, not actually a Technical one.  And not incompatible with the
> coarray TS either!
>
>
>
> As an extra Editorial change, I recommend also [213:4] ?specified team?
> -> ?team identified by /team-val/ue?.
>
>
>
> Cheers,
>
> --
>
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>
>
>
> *From:* j3-bounces at mailman.j3-fortran.org
> [mailto:j3-bounces at mailman.j3-fortran.org] *On Behalf Of *Steidel, Jon L
> *Sent:* Thursday, August 10, 2017 11:45 AM
> *To:* fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
> *Cc:* John Reid <John.Reid at stfc.ac.uk>; Bill Long <longb at cray.com>
> *Subject:* Re: (j3.2006) Comments on some of the comments
>
>
>
> Hi Malcolm,
>
>
>
> These edits have gone back and forth between Bill and John Reid and
> myself.  I started all this by expressing my concern that there is no
> restriction on a CHANGE TEAM or FORM TEAM using a coindexed
> team-variable.  My concern is that a FORM TEAM could define a different
> images team variable, or you could do a change team to a team variable
> that describes a team which the executing image is not a member of.  Do
> you think these things should be allowed?  John and Bill did not think
> that was the intent.
>
>
>
> -jon
>
>
>
> *From:*j3-bounces at mailman.j3-fortran.org
> <mailto:j3-bounces at mailman.j3-fortran.org>
> [mailto:j3-bounces at mailman.j3-fortran.org] *On Behalf Of *Malcolm Cohen
> *Sent:* Wednesday, August 9, 2017 9:53 PM
> *To:* 'fortran standards email list for J3' <j3 at mailman.j3-fortran.org
> <mailto:j3 at mailman.j3-fortran.org>>
> *Subject:* (j3.2006) Comments on some of the comments
>
>
>
> [139:29] The assertion that it is not stated that the team value in an
> image selector has to be defined is false, the standard already states
> ?shall identify the current or an ancestor team?.  The suggested fix for
> this non-problem has forgotten that one is allowed to use assignment of
> team variables (after all, that?s what GET_TEAM is useful for!!!).
> Nothing needs to be done here and this technical change would break the
> language, rendering GET_TEAM unusable for this context.  Do Not Do This.
>
>
>
> [213:3] This is wrong and completely unworkable.  The claim that
> something ?is required? and ?has not been stated? is false on the face
> of it (it?s an internal contradiction!).  The suggested change seems to
> be imagining that when SYNC TEAM happens, it is the same SYNC TEAM
> statement being executed on every participating image.  This imagination
> is false.  In fact the standard already states that the SYNC occurs
> between SYNC TEAM executions ?specifying the same team?, so there is no
> problem that needs to be solved here.  It also breaks assignment of team
> variables for subsequent use in SYNC TEAM, rendering GET_TEAM unusable
> for this context.  Do Not Do This.
>
>
>
> [214:27] The team-variables in FORM TEAM would appear to be already
> required to be separate variables by the segment rules.  There would be
> nothing wrong in principle with
>
>                 FORM TEAM ( myteam(this_image())[1], ?)
>
> which is allowed by the coarray TS.  This usage might be unusual, but
> it?s not inconceivable or wrong.
>
>
>
> This would not be a disaster (unlike the two preceding), but it would
> still be a gratuitous incompatibility with the coarray TS.  Please don?t
> insert more gratuitous incompatibilities.
>
>
>
> P.S. I am not planning to participate in the telecon seeing as how it?s
> at 2am my time?
>
>
>
> Cheers,
>
> --
>
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>
>
>
>
>
> *Disclaimer*
>
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses and malware, and may have
> been automatically archived by Mimecast Ltd, an innovator in Software as
> a Service (SaaS) for business.
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>



More information about the J3 mailing list