Subject: send-receive

From: [email-masked]
Date: Mon, 14 Jun 1993 11:31:13 GMT

On May 28th David Walker started up a discussion on send-receive
operations. Except for one reply by Lyndon Clarke there was not much
feedback. I think we have to have a discussion on this topic,
so I give it another push with this note.

One application of the sendrecv operations is to replace the shift
operation by sendrecv plus a topology routine which provides each
process with the source and destination id to be used in the sendrecv.

An important special case is when for a given process either the source
or the destination process does not exist. In the case of an end-off
shift this happens if data is shifted away from or towards a boundary
process, respectively. I think it would be good if in this case the
boundary process could nonetheless use sendrecv instead of dealing
with the special case explicitely. For this to work properly we would
have to introduce an MPI constant like MPI_NOPID which could be used
as source or destination in sendrecv. Any comments?

As to the number of different sendrecv functions, David wrote:

> I also suggest that we have separate routines for contiguous and
> noncontigous buffers (as for send and receive routines), and separate
> routines for when the input and output buffers are indentical. Thus:
>
>        MPI_SENDRECV
>        MPI_SENDRECVC
>        MPI_EXCHANGE
>        MPI_EXCHANGEC
>
> so there are 4 routines in all.

I agree with this scheme, except that I think that non-blocking versions
would make sense, too. As an example take some grid-based computation,
the grid being split up among the parallel processes. At regular
intervals you have to update grid values in some overlap areas, and
therefore you have to exchange messages with all your neighbors.
Using the non-blocking version of the sendrecv all these operations
can be started at the same time, thus minimizing waiting times due
to bad process synchronization.

Of course we all fear the exponential explosion of function numbers,
but I think we could live with eight sendrecvs.

Rolf Hempel

---

From: [email-masked] (Steve Huss-Lederman)
Date: Mon, 14 Jun 93 09:54:38 EDT

I am trying to reconstruct what happened at the last meeting.  I
recall that both the topology and collective communications groups met
together (the first afternoon?) and discussed this issue.  I thought
that we decided that we should include it (is my memory correct?).  I
also thought that one of the points of discussion was where such a
function belonged.  It is somewhat like a pt-2-pt but having topology
info was nice.  If we include topology info then you don't need the
old EOSHIFT too.  A send-receive function also allows for a
permutation of data on nodes in an easier way.

In summary, I thought the final thoughts were to add it to pt-2-pt and
give the actually sender/receiver with a special value if it is a no
send.  Then there would be topology functions to generate the input
values when the send-receive was to be based on topology information.

I agree that we should discuss this and finalize our thoughts.

Steve