[mpi3-coll] Non-blocking Collectives Proposal Draft

[Richard Graham]

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" <htor at cs.indiana.edu> 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
> mpi3-coll at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-coll
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-coll/attachments/20081019/501cfb44/attachment-0001.html>