[mpi3-coll] Comments on nonblocking collectives section

[Jesper Larsson Traeff]

Dear all,

sorry for my late input. I've had time to read the document, and have found 
something. I refer to the version of 21st January.

Jesper


p. 49, line 26:
"the performance of many systems..." -> 
"the performance of many applications can be improved by overlapping communication
and computation, and many systems enable this."

p. 49, line 28:
"utilize overlap -> "exploit overlap"


p. 49, line 32:
drop "the use of" (grammar: "the use of" is no mechanism)

p.49, line 35:
"a collective communication, which..." -> "a collective communication operation, that..."
("that" better than "which" here?)

p.49, line 36:
"the communication may progress" -> "the collective communication may then progress"

p.49, line 38:
"mitigate synchronizing effects" -> "mitigate synchronization effects"

p. 50, line 9-11: 
drop sentence "Collective operations...", allready said in line 4-7?

p.50, after line 18, add:
"Nonblocking collective requests are not persistent, and MPI_REQUEST_NULL is returned after
successful completion."

p. 50, line 18: 
I still think that MPI_Request_free should be allowed. The rationale also still
reads contrived.

p.50, line 20 (or elsewhere), add:
"Completion of a particular nonblocking collective operations does \emph{not} imply 
completion of any other posted nonblocking collective (or send-receive) operations, 
whether they are posted before or after the operation in case."

p.50, line 24:
"Canceling a request" -> "Canceling a nonblocking request"

p.50, line 24-25:
"cannot be defined clearly." -> "is not well-defined."

p.50, line 33:
"In this sense"?? What does this refer to? Drop, just say "Blocking and nonblocking..."

p.50, line 35:
"In particular," -> "This means that"

p.50, line 44:
"could find an equilibrium between" -> "could attempt to balance"

p. 50, line 47-48:
"than for point-to-point operations." ->
"than for point-to-point operations, where for instance a blocking send can be matched by
a nonblocking receive."

p.50, line 48:
"collective operations is required" -> "collective operation semantics is required"

p.51, line 6 (or elsewhere), add:
"In terms of data movements each nonblocking collective operation upon completion
has the same effect as its blocking counterpart, both for intracommunicators and 
intercommunicators. The use of the "in place" option is allowed exactly as described 
for the corresponding blocking collective operations. Likewise, the nonblocking collective
reduction operations upon completion have the same effect as their blocking counterparts,
and the same restrictions and recommendations on reduction orders apply."

I think this is quite important for the semantic definition of the nonblocking collectives.
The individual remarks for each of the operations could be dropped, although I think
it is good to have them there (for people just checking the one operation they are
interested in). However, the English is in most of the individual cases not good, see
below.

p.51, line 26-30:
Advice reads a bit awkward, but have no suggestion.

p.53, line 37:
"are identical as after a call" - bad Engish, should rather be:
"are the same as after a call".

I would strongly suggest using exactly the same phrase for all of the data moving
collectives! This is not a document being read as a whole, so we don't need to fear
"repetition".

Perhaps add:
"The "in place" option is allowed for intracommunicators, with the same
effect as for MPI_Gather."

p, 54, line 41: Language!

p. 55, line 35: Same
p. 56, line 34: Same
p. 57, line 32: Same
p. 58, line 26: Same
p. 59, line 32: Same
p. 60, line 28: Same
p. 61, line 47: Reads sort of ok here, would still be in favor of using the same phrase
everywhere.

p. 62, line 35-39:
Drop advice to users, but add "The same rules and restrictions as for MPI_Reduce apply."
(consistency is no hobgoblin here, and I think it's important that the nonblocking
collectives "does" the same as their blocking counterparts)


p. 63, line 26: Language.
p. 64, line 11: Sort of OK.
p. 65, line 25: Sort of OK.

p.68, line 21: does a race condition "cause" non-determinism, or is it the other way
round?

p. 68, line 26:
move "outstanding" to "even if there is an outstanding nonblocking..."

p. 69, after line 34:
Would suggest an example 5.31 that shows that e.g. MPI_IAlltoall does not match MPI_Alltoall.

"Blocking and nonblocking collective operations do not match. The following is illegal:"

p.70, line 6:
"the "MPI_Recv." -> "the MPI_Recv call."

p. 70, line 42:
"lower performance" (sounds too colloqial) -> "impact performance negatively." or
"have a negative effect on performance."