[Mpi-forum] MPI "Allocate receive" proposal

[Jed Brown]

"Underwood, Keith D" <keith.d.underwood at intel.com> writes:
> That's just it.  I find it extremely unlikely that the user really has
> a contiguous buffer that they need to receive this stuff into
> (particularly in these examples). 

Hmm, I think the desire for a common receive buffer is common and the
proposed MPI_Arecv would prevent it from being used without both dynamic
allocation and another copy.

> Both of these examples might actually be done *better* with pipelined
> transfers from the peers.  First, you send the count and then you send
> the data in chunks.  Because you cap the size of a chunk, you can
> prepost several receives (ANY_SOURCE) without major fragmentation.
> Pipelining actually allows you to overlap the data transfer with the
> memory copy that you are inevitably doing on both ends.  

It's more complicated code, but I agree that appending the second round
of receives to the request array given to MPI_Waitsome and then acting
on completion of either (creating a second receive when the first
completes or starting processing the data when the second completes) may
be as good as one can hope for.

> In fact, these could be an example of a place where providing a
> different abstraction is going to cause the user to code it in a way
> that is ultimately worse for them (though maybe easier to code).

I'm not arguing with that.  I use constant-size receives in my dynamic
exchange code so that any larger messages will be expected and delivered
to their ultimate resting place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20130826/bd389c39/attachment-0001.pgp>