[mpiwg-rma] summary of ticket #398 discussion

[Jeff Hammond]

Jim wanted this to go on the Wiki but I decided to inline it on the
ticket.  Feel free to copy from or link to the ticket on the RMA WG
Wiki.

Jeff


---------- Forwarded message ----------
From: MPI Forum <mpi-forum at lists.mpi-forum.org>
Date: Tue, Dec 10, 2013 at 3:56 PM
Subject: Re: [MPI Forum] #398: request-based remote completion for RMA
To:


#398: request-based remote completion for RMA
-------------------------------------+-------------------------------------
                  Reporter:          |                          Owner:
  jhammond                           |  jhammond
                      Type:  New     |                         Status:  new
  routine(s)                         |                      Milestone:
                  Priority:  Not     |  2013/03/11 Chicago, USA
  ready / author rework              |                     Resolution:
                   Version:  MPI     |          Implementation status:
  <next>                             |  Waiting
                  Keywords:  RMA     |            Author: Rich Graham:  0
        Author: Bill Gropp:  0       |        Author: Torsten Hoefler:  0
        Author: Adam Moody:  0       |  Author: Jesper Larsson Traeff:  0
     Author: Dick Treumann:  0       |             Author: David Solt:  0
    Author: George Bosilca:  0       |          Author: Rajeev Thakur:  0
Author: Bronis de Supinski:  0       |      Author: Alexander Supalov:  0
      Author: Jeff Squyres:  0       |
 Author: Rolf Rabenseifner:  0       |
-------------------------------------+-------------------------------------

Comment (by jhammond):

 Summary of working group (WG) discussion:

 * The justification of fine-grain remote completion was determined to be
 weak by multiple members of the WG.  The two uses were stated to be CAF
 2.0 and Charm++.  Members of the WG could not come up with a strong
 performance motivation i.e. could not come up with a hardware scenario
 where separation of remote completion would measurably improve
 performance.

 * Brian did not like multiple requests and proposed instead to have a
 single request for a new function that would have end-to-end completion
 semantics, i.e. the completion of the request would correspond to
 '''both''' local and remote completion - no separation of local and remote
 completion is available.

 * Pavan and others believe that nonblocking flush is sufficient to address
 the major issue at hand, which is that blocking flush causes problems.

 * Jim and others believe that returning a request from {{{IWIN_FLUSH} and
 then testing on it is the wrong way to do this and proposes instead to add
 {{{WIN_TEST}}}, which has different semantics than {{{IWIN_FLUSH}}}.  In
 particular, there is no request to be managed.

 * Jeff, Brian and possibly Jim thought that there might be some value in
 adding a SHMEM-like {{{PUT}}} to the MPI standard, which is a Put that
 blocks on local completion so as to eliminate the need for two function
 calls to achieve this effect.  This feature was determined to be out-of-
 scope w.r.t. this ticket and in need of its own ticket if the WG wishes to
 pursue it.

--
Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/398#comment:4>
MPI Forum <https://svn.mpi-forum.org/>
MPI Forum


-- 
Jeff Hammond
jeff.science at gmail.com