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 <[email protected]> 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 [email protected]