"Underwood, Keith D" <[email protected]> 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.