Subject: thoughts

From: [email-masked] (Steve Lederman)
Date: Wed, 9 Dec 92 16:51:10 EST

I have a few thoughts on the ideas that have been passed around.  I'm
sorry for not responding sooner but a cold has slowed me down.

First, on Marc's document of Nov. 28:

- Goal 4 is for a C, C++, F77 and F90 binding.  The draft Intro
that Jack sent around on Nov. 30 states in the subsection for Who
Should Use This Standard? that it is for Fortran 77 and/or C.  Do we
wish to include C++ and F90 which would likely to have different
interfaces?

- I find the SEND_RECV operation an interesting option.  On the old
Mark/?? machines from Caltech/JPL there was a call (if my
recollection is correct) that allowed for the same user buffer to
serve as the send and receive buffer.  I assume this is not what is
intended here?  I think SEND_RECV would be used with some frequency by
users.  Would it simply be a convenience or can it be made faster than
issuing the two calls.  I would think it would be faster on some
architectures (even more than the two call overhead).  If it is faster
then my inclination is to include it even though it adds another call.
comments?

- I have a question regarding when a communication operation is
completed.  On a send, does it terminate locally if the user buffer is
copied into a system buffer but has not left the node?  (I believe
this is done on the CM5.)  Analogously, does it terminate globally if
it gets to a system buffer on the receiving node or until it is in the
user buffer?  As for choosing local, global or both I vote for the
current choice of both.  I can see applications for both.

- I think that Marc's suggestion that MPI functions not return
unsuccessfully has merit.  It would be pain to be constantly checking
the status after each operation to be safe.  Along these lines is what
to do if the send and recv message lengths are different.  The current
standard allows for fewer bytes to be received and the recv returns
the actual number.  Again, I think it would be a pain to have to check
every time.  If this is a desirable feature to allow different
lengths, then I vote to make it users selectable.  I know I have found
many bugs by not having messages that were a different size being
received.

- I think that a PROBE function would be a good idea.  Given that the
standard is not currently going to support active messages, etc. it
seems that being able periodically check if any messages have arrived
would be a useful feature.

Another thought:

At the meeting in Minneapolis, several people, including myself,
discussed the advantage of having a send where the sending process
knows the receiving process has already posted a receive.  This could
relieve the send process of having to check with the receiving process
since it knows it will not have to buffer the message in system space
and it knows it is ready to receive the message.  If a system could
not take advantage of this then it could revert to a normal send.
That is, the standard would not specify the way the send would occur,
it would allow for an alternative protocol if the vendor wished.  This
is the rr (receiver ready) option in Bill Gropp and Ewing Lusk's
implementation.  I would like to propose we include this in the
standard.  Thoughts?

Well enough for one message.

Steve