[mpi3-coll] Non-blocking Collectives Proposal Draft

Richard Graham rlgraham at ornl.gov
Sun Oct 19 19:50:04 CDT 2008

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
  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.


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>

More information about the mpiwg-coll mailing list