[mpi3-coll] New nonblocking collective intro text

[Torsten Hoefler]

Adam, Christian,
oh - this mail was delayed at my mailserver, ignore my reply to the
previous one.

>> 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.
>
> It's a bit repetitive, I know.  To make a direct parallel, I copied the  
> same sentence structure used in the nonblocking point-to-point section  
> (see the 2.1 document, page 47, lines 46-48).  We could drop the "but  
> does not complete it" clause to shorten this some (saves one "complete"):
>    "A nonblocking start call initiates a collective operation, which  
> must be completed in a separate completion call."
ok, I revert my "might" if the point-to-point chapter mandates a
completion function. I implemented your proposal from above.

>> 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."
>
> I'd be ok with dropping a "complete" here, as well, although I prefer  
> "which must be passed" over "which is eventually passed":
>    "The start call returns a request handle, which must be passed to a  
> completion call."
sounds good - implemented this.

>>
>> 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.
>
> I added the "implied by" to address cases like MPI_Alltoall, where there  
> is no specified synchronization as in MPI_Barrier, but clearly a process  
> can't complete until it has received data from every other process and  
> thus knows all other processes have started the call.  I have no  
> objections to dropping one of these two phrases.  Going with just  
> "implied by" leads to a cyclic-sounding statement.
>    "Completion does not imply that other processes have completed or  
> even started the operation unless otherwise implied by the description  
> of the operation."
> We could just go with "specified in":
>    "Completion does not imply that other processes have completed or  
> even started the operation unless otherwise specified in the description  
> of the operation."
I'm fine either way. The existing text in MPI-2.1 never mentiones this
implied by, so I'll drop it (it should be intuitive).

>> 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.
>
> Yes, I agree, but I'll leave this alone as it is a bigger discussion for  
> the group.
we discussed that setting this would cause unnecessary overheads.

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