Here are my comments: These are from the original draft sent out, so other may have already commented on some of these ­ could not download from the web on the plane :-) Section 1.2 paragraph 2: The matching of those operations a is ruled by the order.... This is a bit confusing, as the paragraph mentions both point-to-point operations and blocking collective operations. I would suggest changing this to ³The matching of those blocking collective operations is rules by the order ....² Section 2: ³High-quality ...² - In general I am against these sorts of comments, even though they are strewn throughout the standard. There are many tradeoffs in implementing a communications library, and what may be good in one instance, may not be appropriate in another. It may be more appropriate to state ³The enables the application to take advantage of asynchronous progress, if the implementation implements such a capability...² While I agree with the sentiment, I disagree with the categorization. Section 2.1: Instead of using the term nested collectives, multiple outstanding non-blocking collectives seems clearer to me. The comment that calling MPI_Request_free() is not useful on the send side is not quite clear to me. Why is the send side different from the receive side ? In either case, I do not think that we should allow freeing a request in the middle of a collective (like one can for ptp communications) The paragraph on the bottom of page 3 is confusing. After mentioning that we can have multiple outstanding collectives, the last sentence seems to imply that in such a case, all would have to be of the same type (such as ibcast), which I do not think is the intent. Section 2.3: As I mentioned before, I do not believe we should specify that an implementation should support more than a minimum of 1 (i.e must provide support for this). Especially as the system sizes increase markedly, we need to be careful on what sort of resource requirements we place on an implementation. Rich On 10/16/08 4:46 PM, "Torsten Hoefler" <[email protected]> wrote:

Hello Alexander,

...

...

Generally, some sentences start with lower case letters that should be capitalized. yes, I fixed some but will re-read it later this week.

...

...

Page 3, top. We probably should not explain here how to ensure progress for nonblocking ops. This matter should be covered by the general progress description elsewhere. I agree, I deleted it (it's already in the nonblocking point-to-point chapter).

...

...

Page 3, lower half. Look how progress is defined in this list by referring to the pt2pt progress rules. what do you mean with that? I would just reference the current MPI definition - NBCs seem to fit this model nicely.

...

...

Ibid. There are already 3 classes of requests: pt2pt, generalized, and file I/O ones. yes

...

...

Page 3, bottom. How many nonblocking ops can overlap with a blocking one? I.e., can one have the following situation:

Process 0 Process 1

MPI_Ibarrier(req) MPI_Ibarrier(req) MPI_Wait(req) MPI Bcast MPI_Bcast MPI_Wait(req) yes, this is a legal code and should work. Any objections?

...

...

Page 5, bottom. 32767 simultaneous ops to support is a tall order. I'd say, 1 (one) would be a good lower limit, thus allowing no overlap. Or even 0 (zero), meaning no nonblocking collective support at all. The rest of this passage would probably be better reformulated as an advice to implementors. yes it is - I'm very indicisive. We have to discuss this at the Forum in Chicago.

...

...

In the margin: editing a PDF requires creativity (exemplified by the earlier comments) or a pretty expensive Acrobat. Maybe we can find some other way of distributing and commenting on our drafts? oh yes, I fully agree. But the final document should be in MPI style, so I thought I should start with LaTeX. Do you have any suggestions? Wiki seems suboptimal because we would have to re-format everything (which might be not too bad). LaTeX source in svn would be the best, but does everybody have LaTeX? I'm open for any suggestion!

For now, I uploaded the changed version to the wikipage (to avoid attachments on the mailinglist): https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/NBColl

Thanks for the comments!

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 _______________________________________________ mpi3-coll mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-coll