[Mpi3-rma] non-contiguous support in RMA & one-sided pack/unpack (?)

[Richard Treumann]

The assertion could then be: MPI_NO_SLOW_RMA (also a bit tongue in cheek)

My argument is that any RMA depends on a call at the origin being able to
trigger activity at the target.  Modern RMA hardware has the hooks  to do
the remote side of MPI_Fast_RMA_xfer() efficiently based on a call at the
origin. Because these hooks are in the hardware they are simply there. They
do not use the CPU or hurt performance of things that do use the CPU.

RMA hardware may not have the hooks to do the target side of any arbitrary
MPI_Slow_RMA_xfer().  As a result, support for the more complex RMA_xfer
may require a wake-able software agent (thread maybe) to be standing by at
all tasks just because they may become target of a Slow_RMA_xfer.

If having this agent standing by hurts general performance of MPI
applications that will never make a call to Slow_RMA_xfer, why not let the
applications author promise up front "I have no need of this agent."

An MPI implementation that can support Slow_RMA_xfer with no extra costs
(send/recv latency, memory, packet interrupts, CPU contention) will simply
ignore the assertion.

BTW - I just took a look at the broad proposal and it may contain several
things that cannot be done without a wake-able remote software agent. That
argues for Keith's idea of an RMA operation which closely matches what RMA
hardware does and a second one that brings along all the bells and
whistles. Maybe the assertion for an application that only uses the basic
RMA call or uses no RMA at all could be MPI_NO_KITCHEN_SINK (even more
tongue in cheek).

           Dick


Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363


mpi3-rma-bounces at lists.mpi-forum.org wrote on 09/16/2009 01:08:51 PM:

> [image removed]
>
> Re: [Mpi3-rma] non-contiguous support in RMA & one-sided pack/unpack (?)
>
> Underwood, Keith D
>
> to:
>
> MPI 3.0 Remote Memory Access working group
>
> 09/16/2009 01:09 PM
>
> Sent by:
>
> mpi3-rma-bounces at lists.mpi-forum.org
>
> Please respond to "MPI 3.0 Remote Memory Access working group"
>
> But, going back to Bill’s point:  performance across a range of
> platforms is key.  While you can’t have a function for every usage
> (well, you can, but it would get cumbersome at some point), it may
> be important to have a few levels of specialization in the API.
> E.g. you could have two variants:
>
> MPI_Fast_RMA_xfer():  no data types, no communicators, etc.
> MPI_Slow_RMA_xfer(): include the kitchen sink.
>
> Yes, the naming is a little tongue in cheek ;-)
>
> Keith
>
> <snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20090916/ceca1fff/attachment-0001.html>