(j3.2006) (SC22WG5.5034) [ WG5 vote on draft TS on further coarray features]
Van Snyder
Van.Snyder
Wed Jul 10 22:50:00 EDT 2013
ISO/IEC JTC1/SC22/WG5 N1986
WG5 letter ballot on N1983
John Reid, 10 July 2013
This is a WG5 letter ballot on N1983, the second draft DTS for
TS 18508, Additional Parallel Features in Fortran.
N1967 has the same content as J3/13-293. It was prepared by the editor,
Bill Long, following the meeting of WG5 and J3 in Delft. Details of
the changes made from the first draft, N1967, are given in J3/13-294.
The basic requirements were changed during the meeting in Delft and
are given in N1981, which supersedes N1930.
Please answer the following question "Is N1983 ready for forwarding to
SC22 as the DTS?" in one of these ways.
1) Yes.
2) Yes, but I recommend the following changes.
3) No, for the following reasons.
I have identified at least 31 places where change appears to be
necessary. Most of these are niggling details that would reasonably
fall under the rubric "Yes, but I recommend the following changes."
The problem that causes me to vote "No" is that CHANGE TEAM doesn't
accomplish the necessary rearrangement of coindexing for coarrays having
corank > 1. Adding "<team-variable> ::" to <image-selector> doesn't
solve the problem, and is a fundamentally bad idea.
Two files are attached. One is a list of the mostly-niggling changes,
and the other is a proposal, stimulated by the ideas immanent in the
ASSOCIATE construct, to deal with the rearrangement problem for coarrays
having corank > 1.
4) Abstain.
This is an individual vote. Please send your vote to
sc22wg5 at open-std.org
to arrive by 9 a.m. (UK time) on 12 August 2013.
-------------- next part --------------
[9:18] Insert "variable" after "scalar".
[10:13-14] Values of variables are not "formed," they are defined.
[10:27-32]
Image selectors don't solve the problem that motivated the discussion
that led to them. In any case, they seem to be a fundamentally bad
idea, somewhat akin to the idea that a subroutine can access a
sequence-associated dummy argument array using subscripts relative to
the actual argument. A proposal to solve the original problem is
attached.
[11:1] "form-team-spec" -> "form-subteam-spec"
[11:4-6]
One could calculate a team variable describing the initial team by
executing a FORM SUBTEAM statement in which <subteam-id> has the same
value on all images.
If this would be a common thing to do, it would be useful to have a team
variable describing the initial team, maybe in ISO_FORTRAN_ENV.
[11:6] Restricting <subteam-id> to be positive seems pointless. Can it
at least be non-negative? One might reasonably want to use
mod(this_image(),2), instead of 1+mod(this_image(),2) or
2-mod(this_image(),2).
[11:9] "a different value" -> "different values"
[11:13] "on" -> "in" or "these statements" -> "images of the current
team"
[11:17]
A prohibition against changing the value of a team variable during
execution of a CHANGE TEAM construct appears to be necessary.
Otherwise, how does synchronization at the END TEAM statement work
reliably? Does the processor keep a cached copy of the team variable,
maybe on something like a "team stack," just in case it's changed? The
restriction at [11:17] doesn't cover this problem. Maybe it's enough to
insert "or the current team".
[11:21] "FORM SUBTEAM" -> "a FORM SUBTEAM statement"
[9:17] and [13:7] use inconsistent style.
[13:15] "in a" -> "in an"
[13:24] Is the EVENT POST statement the only way to post an event? It
would be neutral to say "Execution of an EVENT POST statement posts an
event."
[13:31] Is the EVENT WAIT statement the only way to wait for an event?
It would be neutral to say "Execution of an EVENT WAIT statement waits
until an event is posted."
[14:1-2] What is "success" for a wait? Is it waiting, or continuing
without needing to wait, or what?
[15:3-4] lines are wider than the margins. Look for "overfull hbox"
after running LaTeX.
[15:11-13] First two sentences are redundant. Delete the first one.
[16:15] "scalar of the same type as ATOM" -> "scalar and of type
integer" or "scalar and of type integer with the same kind as ATOM"
(whichever is really intended). Also at [16:29], [17:21], [17:34].
[16:18] Delete "have its"
[16:35] It's hard to justify "swap" in the description of a subroutine
in which only one argument has INTENT(INOUT). Swap what with what?
[17:4] We don't have a concept of equality for objects of logical type.
Appears to require a messy sentence using "equivalent," or maybe two
sentences.
[18:5] Is the image index an index in the current team or the initial
team? Also [18:25], [19:10], [19:44], [20:31]
[19:29] If SOURCE is scalar, is it required to have the same type
parameter values on all images?
[19:32] "parameters" -> "parameter values"
[21:7] Why default integer? Why not a kind for which HUGE(0_thatkind)
>= HUGE(0)?
-------------- next part --------------
WG5/N19xx
To: WG5
Subject: Accessing team coarrays in subteams
From: Van Snyder
Date: 27 June 2013
1. Problem description
----------------------
It is desired to access a portion of a coarray created in a team, either
by static declaration or allocation, within a subteam created by a
CHANGE TEAM construct, using cosubscripts such that the range of
accessible coelements, taken in coarray coelement order, is bounded by
the size of the subteam. Further it is desirable that the portion of
the coarray that is accessible within a subteam depends upon the
membership of the subteam. It is undesirable for the subteam to be
required to be aware of the mapping from coelements of the entire
coarray to coelements germane to the subteam.
The correspondence between image indices and coelements applies only to
the indexing of coelements, taken in coarray coelement order. If one
needs to revise the leading codimension extent(s), CHANGE TEAM offers no
help.
2. Example
----------
As a simple example, assume a corank-2 coarray:
real :: A[10,*]
Assume the number of images has been verified to be 100, and four teams
are formed:
integer :: ME, S, S1, S2
type(team_type) :: T(2,2)
me = this_image()
s2 = merge(1,2,me>49)
s1 = merge(1,2,mod(me-1,10)>4)
s = s1 + 2*s2
form subteam ( s, t(s1,s2) )
Assume it is desired that subteam 1 accesses the A[1:5,1:5]
coelements of A, subteam 2 accesses the A[6:10,1:5] coelements of A,
subteam 3 accesses the A[1:5,6:10] coelelements of A, and subteam 4
accesses the A[6:10,6:10] coelements of A.
Assume subteams are entered thus:
change team ( t(s) )
! At this point, valid image indices are 1..25, in each
! subteam. Which coelements of A[] are accessible in subteam S?
! Presumably, coelements 1..25, taken in coarray coelement order
! are accessible in subteam 1, 26:50 in subteam 2, 51:75 in subteam
! 3, and 76:100 in subteam 4. But subteam 1 wants 1:5, 11:15,
! 21:25, 31:35, and 41:45, while subteam 2 wants 6:10, 16:20, 26:30,
! 36:40, and 46:50, subteam 3 wants 51:55, 61:65, 71:75, 81:85 and
! 91:95, and subteam 4 wants 56:60, 66:70, 76:80, 86:90, and 96:100.
..
end team
3. Proposal
-----------
A scheme to re-map cosubscripting is needed.
There is presently no concept of a cosection, and no concept of
cosequence coassocation. Therefore, for example, assuming the
subroutine executes a CHANGE TEAM construct, the following is not even
valid syntax:
call do_teams ( s, t(s), a[1+5*(s1-1):5*s1,1+5*(s2-1):5*s2] )
This would be nontrivial to implement, and very difficult or impossible
if vector cosubscripted cosections are allowed, at least if it is
necessary to avoid copying. Vector cosubscripted cosections might be
indispensible in adaptive grid applications.
An alternative that would solve the same problem, but also is not (yet)
valid syntax, might be something like
change team ( t(s)), a1 => a[1+5*(s1-1):5*s1,1+5*(s2-1):5*s2] )
! Herein, A1 is a coarray that is coassociated with the specified
! coelements of A on each subteam.
...
end team
Vector cosubscripted cosections would not be an insurmountable problem
within the CHANGE TEAM construct, because the processor clearly could
see the vector. If the subteam coarray is an actual argument, however,
the vector needs to go along with it. Even if the team coarray does not
have a vector cosubscript, a descriptor needs to accompany a coarray
argument. This might be included in the team variable, which would then
need to accompany coarray arguments. Even without this proposal, it
might be necessary for team variables to accompany coarray arguments.
4. Draft proposed edits to N1983
--------------------------------
[9:36] Replace "<sync-stat-list>" with "<change-list>"
[9:36+] Insert syntax rules and constraints
R502a <change> <<is>> <sync-stat>
<<or>> <coassociation>
R502b <coassociation> <<is>> <subteam-coarray> => <team-cosection>
R502c <subteam-coarray> <<is>> <name>
R502d <team-cosection> <<is>> <coarray-name> <lbracket>
[ <coselector> ] ... <final-coselector>
<rbracket>
R502e <coselector> <<is>> [ <lower-cobound> : ] <upper-cobound>
[ : <costride> ]
<<or>> <vector-subscript>
R502f <final-coselector> <<is>> [ <lower-cobound> : ] *
[ : <costride> ]
R502g <lower-cobound> <<is>> <scalar-int-expr>
R502h <upper-cobound> <<is>> <scalar-int-expr>
R502h <costride> <<is>> <scalar-int-expr>
R502g (R503d) The <coarray-name> shall be the name of a coarray.
C502a (R503d) The number of <coselector>s shall be equal to the corank
of <coarray-name>.
C502b (R503d) There shall be at least one <coselector> that includes a
colon, is an asterisk, or is a <vector-subscript>.
C502c (R503e) If <coselector> is <vector-subscript>, <subteam-coarray>
shall not appear as an actual argument.
[10:16+] Insert a paragraph:
"If <coassociation> appears, the <subteam-coarray> is the name of a
coarray that is coassociated with the specified <team-cosection>, in
coarray coelement order. The corank of the <subteam-coarray> is the
number of <coselector>s that include a colon, is an asterisk, or are
<vector-subscript>s. Within the CHANGE TEAM construct, the number of
coelements of <subteam-coarray> is equal to the number of images in the
subteam."
Definitions of terms "coassociated", "coelement", and "coelement order"
are needed as well.
More information about the J3
mailing list