[mpi3-coll] New nonblocking collective intro text

[Torsten Hoefler]

Hi Christian,
> I very much appreciate many of your textual improvements. However, it is  
> very time consuming for us as reviewers to keep track of such  
> substantial changes. It would have been much easier, if you had  
> contributed your changes in an earlier stage. Anyway, I waded through  
> the changes to revision 3 and will comment only on the things that I  
> don't like (consider everything else as excellent):
>
> I second Torsten's opinion on p. 49, l. 35-37: This reformulation  
> introduces three times the term "complete". Besides this drawback, I  
> also don't see any benefit from this reformulation compared to the  
> previous version.
ok, so I reformulated "A nonblocking start call initiates a collective
operation, but does not complete it. A separate completion call is
needed to complete the operation."

to

"A nonblocking start call initiates a collective operation and a
completion call might be needed to finish the operation."

I introduced "might" because the initialization is allowed to finish the
operation (semantically) - think of MPI_COMM_SELF.

> p. 50, l. 1-2: Similar problem (i.e. 2x"complete"). May I propose: "The  
> start call returns a request handle, which is eventually passed to a  
> completion call."
we should stick to imperative voice in the standard. I think we're not
writing a novel and this repetition is acceptable in a technical
document.

> p. 50, l. 8: The part "unless otherwise specified in, or implied by, the  
> description of the operation" has been added. Seem ok to me at first  
> glance. However, we might re-check if this is really necessary and drop  
> it otherwise.
MPI_Ibarrier() specifies this

> p. 50, l. 16: This looks quite redundant to me. I'd propose sth. like  
> the following restatement: "Upon completion of a nonblocking collective  
> operation, the MPI_ERROR field...".
ah, there is a slight semantic difference between "returning from a
completion call" and "completion". I think the current wording is less
abiguous.

> p. 50, l. 17: The added postfix "to indicate any errors" seems wrong to  
> me because MPI_SUCCESS is also a valid entry for the MPI_ERROR field.  
> I'd propose to simply omit this postfix. However, I'm not 100% sure  
> because the section about the MPI Status object looks quite confusing in  
> this respect. Btw. there exists also an empty status (which sets all 3  
> fields) - so we might need to reconsider our decision about setting only  
> the error field for nonblocking collective operations.
omitting it is a safe way of avoiding mistakes. It's gone now and just
says "is set appropriately" which is defined elsewhere.

> p. 50, l. 29: "nonblocking collective communications" => "nonblocking  
> collective operations"
fixed

> p. 50, l. 44: You changed "running time" to "minimal time to completion"  
> - this is _not_ the same thing! I'd strongly prefer to stay with the  
> previous terminology.
why? I'll leave it as is for now.

> p. 62, l. 36/37: now we have two consecutive "the"s
fixed

Updates are in rev. 3.

Thanks,
  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