To: J3                                                     12-162
From: R. Bader
Subject: Comments on coarray requirements draft
Date: 2012 June 22
References: N1924


Ad 2. Teams:
~~~~~~~~~~~~

2.1 Coindexed access to objects in ancestor teams

    If it is decided to allow access to coindexed entities defined in
    ancestor teams via the array(:)[i,j]@team notation, the team objects
    must allow for global accessibility. This could, for example, be
    achieved in a manner similar to locks i.e., teams could be required
    to be coarrays. On the other hand, this might make usage more
    inflexible because team objects could not generally appear as
    type components.

2.2 Coarrays with the SAVE attribute

    Coarrays that - either explicitly or implicitly - have the SAVE
    attribute should be required to be bound to the initial ("world")
    team. Anything else would probably lead to considerable consistency
    problems (on the standard's side, possibly complicated rules would
    need to be made up to avoid these, and programmers will have
    difficulties obeying them).

2.3 Changing teams

    T4 has the requirement that not only the members of the new team,
    but also those of the old team should be synchronized on entry to
    the block construct that selects subteams. I disagree with this
    because I think there exist situations where unsynchronized
    execution can provide a performance advantage. The only place
    where synchronization is necessary is where the teams are created.
    Otherwise, the programmer can and should control synchronization
    via SYNC ALL or allocation statements inside the block construct.
    Alternatively, one could also consider adding an "async" modifier
    to the block construct entry / exit statements to enable
    performance optimization.

Ad 3. Collectives:
~~~~~~~~~~~~~~~~~~

    The experiences with interconnects with offload capabilities
    indicate that the MPI-3 functionality of "immediate"
    i.e., asynchronous collectives should at least potentially be
    enabled for the TS collectives. Since TS29113 has already extended
    the semantics of ASYNCHRONOUS entities, this concept could
    be carried a bit further here, making the collectives belong to
    the set of routines that can be executed asynchronously, using
    additional optional arguments to control whether or not to use this
    facility.
    Similar to asynchronous I/O, an implementation may or may not
    perform immediate execution even if these additional arguments are
    present; there is hence no pressure on vendors to actually
    provide an efficient implementation (in particular if the underlying
    hardware cannot translate this to a real-world performance boost).
    The WAIT statement could be used to finalize execution of an
    ASYNCHRONOUSly executed collective.

Ad 5. Events:
~~~~~~~~~~~~~

    One-side ordering of segments as requested in E.1 is already available
    in the context of locks and critical regions; E.1 therefore should
    add the requirement that this must be asymmetric, with the notifying
    image never blocking execution.

    With respect to Bill Long's comment: I also consider a put-with-notify
    desirable for performance; can the syntax of using this feature
    be kept as near as possible to regular coarray "put" syntax?