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

Richard Treumann treumann at us.ibm.com
Wed Sep 16 16:05:03 CDT 2009


Hi Jeff

I do not understand the need for two distinct origin side operations if you
will assume the agency infrastructure must always be standing by ready to
be activated.

The MPI implementation will be able to determine at the origin side if the
parameters passed into a complex RMA fit the capabilities of its NIC. It
can decide whether to use the intrinsic NIC mode or the software agent
mode.  If it has a NIC that does integer accumulate but not floating point
accumulate, the implementation can pick between NIC mode and agent mode.
When a new NIC that does floating point accumulate comes along, the
implementation can exploit it with no need for application rewrite.

On the other hand, the RAW RMA can be used by by applications that want to
exploit NIC capabilities that are widely available today and do not want to
drag in overheads for an agent waiting on the sidelines. An agent that they
may know will never be needed. If someday in the future the typical NIC has
certain additional capabilities we can add a richer RAW operation to the
MPI standard.

Can you explain to me what you expect to have always available as a
software agent that will be there at no significant cost in memory or harm
to performance of non-RMA operations?

Are you thinking we need two distinct routines just to avoid a couple "if"
tests to decide inside libmpi whether to use NIC based or agent based RMA?

             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



                                                                                                                     
  From:       Jeff Hammond <jeff.science at gmail.com>                                                                  
                                                                                                                     
  To:         "MPI 3.0 Remote Memory Access working group" <mpi3-rma at lists.mpi-forum.org>                            
                                                                                                                     
  Date:       09/16/2009 04:37 PM                                                                                    
                                                                                                                     
  Subject:    Re: [Mpi3-rma] non-contiguous support in RMA & one-sided    pack/unpack (?)                            
                                                                                                                     
  Sent by:    mpi3-rma-bounces at lists.mpi-forum.org                                                                   
                                                                                                                     





<snip>

I'm not sure I understand all this talk about assertions upon
initialization, since I was hoping that Raw_xfer and general-purpose
xfer (Gen_xfer) would both always be available but that the former
would be much faster in certain contexts, since implementing the Raw
version close to hardware doesn't require much work and would not
interfere with how Gen_xfer operates.  Am I missing something?

<snip>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20090916/d401a121/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20090916/d401a121/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20090916/d401a121/attachment-0003.gif>


More information about the mpiwg-rma mailing list