Hi,
> I don't know if we want to list *every* section for the reduction
> collectives. (We don't do this for other collectives like alltoall,
> alltoallv, alltoalw) I think we could simplify a couple:
> p 1, lines 41-42
> Simplify:
> "where the result is returned to all members of a group (Section
> 5.9.6 and Section 5.12.8) and a variation where the result is returned
> to only one member (Section 5.9 and Section 5.12.7)."
> to:
> "where the result is returned to all members of a group and a
> variation where the result is returned to only one member (Section 5.9,
> Section 5.12.7, and Section 5.12.8)."
nope, we actually do this for Alltoall
> p 1, lines 47-48
> Simplify:
> "(Section 5.11, Section 5.11.2, Section 5.12.10, and Section 5.12.11)"
> to:
> "(Section 5.11, Section 5.12.10, and Section 5.12.11)"
same, I think it's important to either list all sections or none. I am
in favor of listing the sections right now (not strongly, but it's
consistent with 2.2).
> Mixing call and operation
> p 2, lines 18-20
> Change:
> "A blocking operation is complete as soon as the call returns. A
> nonblocking (immediate) call requires a separate completion operation"
> to:
> "A blocking operation is complete as soon as the call returns. A
> nonblocking operation requires a separate completion call"
nope, that's actually meant as written, i.e., if I start an operation
(with a nonblocking call), then I *must* complete it.
> Missing a "nonblocking":
> p 50, line 5
> "Similarly to the blocking case, collective operations ..." -->
> "Similarly to the blocking case, nonblocking collective operations ..."
I think it's correct as stated (this sentence applies to blocking and
nonblocking colls) but sounds awkward -> changed
> We should also stress local-ness of completion in the "i.e." phrase
> p 5, line 7
> "i.e., the semantics of the operation are guaranteed" --> "i.e.,
> for the caller, the semantics of the operation are guaranteed"
hmm, that doesn't change anything - who's the caller? Everybody has to
call the collective, so everybody is the caller. We could introduce the
notion of local completion again here, but we just removed it because we
defined "completion" as generally local.
> Since we are now using the word "indicate" in the first sentence, it'd
> be good to use this same word in the following "also" sentence.
> p 50, line 10
> "does not imply" --> "does not indicate"
ok, I don't care
> I think it'd read better to mention the "in place" buffer restriction
> following the other sentence about "in place" near the end.
> p 50, line 1-2, remove sentences
> "When using the "in place" option, ... Such buffers ... until the
> operation completes."
> p 51, lines 9-14: Split this paragraph into two and add the removed
> sentences from above (I also added "Once an operation is initiated").
> The result paragraphs read:
> In terms of data movements, each nonblocking collective operation has
> the same effect as its blocking counterpart for the intracommunicators
> and intercommunicators after completion. Likewise, upon completion,
> nonblocking collective reduction operations have the same effect as their
> blocking counterparts, and the same restrictions and recommendations on
> reduction orders apply.
> The use of the "in place" option is allowed exactly as described for
> the corresponding blocking collective operations. When using the "in
> place" option, message buffers function as both send and receive
> buffers. Once an operation is initiated, such buffers should not be
> modified or accessed until the operation completes.
ok, I don't mind - changed
> Verb tense of "call" and keep the "only" keyword from blocking description:
> p 51, line 36
> "the operation completes after every process in the communicator
> called MPI_IBARRIER" --> "the operation completes only after every
> process in the communicator calls MPI_IBARRIER"
hmm, I don't mind - but I used "have called" as tense because that's
consistent with the blocking description.
> Expand intercommunicator sentence for MPI_Ibarrier
> p 51, lines 36-37
> Replace:
> "On intercommunicators, the operation completes when the MPI_BARRIER
> call would return."
> with:
> "On intercommunicators, the operation completes for processes in one
> group (group A) of the intercommunicator only after all processes in the
> other group (group B) call MPI_IBARRIER."
ok, we need to merge all other MPI-2.2. items later also ;).
Best,
Torsten
--
bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler | Postdoctoral Researcher
Open Systems Lab | Indiana University
150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA
Lindley Hall Room 135 | +01 (812) 855-3608