[mpi3-coll] Non-blocking Collectives Proposal Draft

Torsten Hoefler htor at cs.indiana.edu
Thu Oct 16 15:56:38 CDT 2008

On Wed, Oct 15, 2008 at 04:02:41PM +0200, Christian Siebert wrote:
> @Torsten:
> Thanks a lot for this first draft! I tried to make some useful comments 
> and attached the results to this mail (sorry, I can't comment PDFs so I 
> did it the "old inconvenient way").
oh yeah - we should not send too bi attachments to the list (your mail
was 2.3 MiB). I fixed all remarks in the scans. See attachment at:

> @Working Group (something to discuss):
> 1) The MPI-2.1 document has 127 occurrences of "nonblocking" and only 8 
> occurrences of "non-blocking". What would be the correct term? Should we 
> try to be more consistent?
no comment ;) - see ticket #44

> 2) Clarification of MPI_Request_free() for requests from non-blocking 
> collective operations.
what do you mean? 

> 3) Better definition/description for "matching" (there is nothing like 
> "at the same time" -> logical order?).
yes, do you have a suggestion? I replaced it with simultaneously for now
- which is suboptimal too. 

> 4) Define "levels of progression"? To be queried (e.g., for "Synchronous 
> Progress" MPI_Tests are needed for performance, but for "Asynchronous 
> Progress" they would only add unnecessary overhead)? UP >= AP >= SP?
yes, I actually erased those definitions because they don't belong in a
standard (imho). 

> 5) "Unexpected Progress" => "buffered" collectives?
this is also gone - this is an implementation detail, not an interface

> 6) NBC gives several possible ways for optimizations. With this "General 
> advice to implementers" we stick to only one, and might prevent others. 
> Can we already fix a decision for optimization strategies at this stage? 
> Should we fix it at all?
this is only an advice. Maybe you're right, but I don't think that it'll
be much better without the advice at all. Advices seem to be rather weak
anyway so I have no strong opinion on that.

> 7) Should there be a concrete code example in the proposal (e.g. an 
> implementation of this double buffering example)?
maybe, doesn't sound too bad. Let's talk about this at the Forum

I just started to creat an agenda for Chicago and put hose items on
there (more will follow).

> Hope this isn't too much for now.


 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

More information about the mpiwg-coll mailing list