Subject: READY Send Rationale Please.

From: Steven Ericsson Zenith <[email-masked]>
Date: Mon, 15 Mar 93 15:15:27 -0600

Someone please give me a rationale for Ready Send.

Doesn't Ready Send add overhead to every point-to-point communication?
In a dumb implementation (i.e. one that isn't able to analyse the usage
and detect that I never - ever - use Ready Send) receives will feel
constrained to notify senders in all cases on the off chance that one is
a Ready Send. This restricts good implementations that do not require
such a dumb primitive.

Further, given the non-ready state caveat "outcome is undefined" and a
system where I cannot know, or choose not to know, the readiness of
receives - am I able to optimize away the use of Ready Sends? If I am, as
seems likely, I suggest we optimize it out of the standard. It is
certainly going to complicate the formal specification and its removal
further simplifies the number of calls.

The only rationale I could think of (excepting that I have a dumb
implementation of communication ;-) ) is memory mapped I/O devices - but
a) I thought for some reason that that was not within the scope of MPI,
and b) in any case, such should not be allowed to impact on the general
primitives - there are better solutions.

But please, if someone has a plausible rationale to keep Ready Send in
this standard, let's hear it.

Steven
PS. We'll get to a single well defined "send" and "recv" yet! ;-)

---

From: [email-masked] (Steve Huss-Lederman)
Date: Mon, 15 Mar 93 17:38:44 EST

The Ready Send was added because it can reduce overhead in some
systems.  As the current draft states:  "On some systems, this will
allow to optimize communication and avoid a hand-shaking operation
that is otherwise required."  On many message passing systems the
sender must probe the receiver to make sure that space is available
before the send can occur.  On some system(s) this is done for each
set of packets sent.  With Ready Send, the sender knows that the
receive is posted and does not need to send a probe message to check
and this can reduce latency and increase throughput.  A good
algorithmic example of its use is for a global combine where the
result winds up in every node.  If you use a minimum spanning tree to
a root node, the receives can be posted before the nodes contribution
to the global value is passed on.  When the root node uses the inverse
tree to fan the answer back out, it can use a Ready Send without any
chance of losing data.  I think it has reasonable uses.  One can
question whether is deserves to be in the standard given the added
complexity of additional choices.  However, after two votes of yes for
this construct, I think we should leave it unless there is a global
move to simplify MPI.

Steve