[Mpi3-rma] [EXTERNAL] Re: request-based ops

[Jim Dinan]

Brian,

Can you elaborate on the source of performance loss from operations between
Iflush and its completion?

Jeff,

I think the pirate RMA (separate per operation local/remote completion)
idea is good.  I'm not sure I'm sold on the interface; I'd rather not add
so many new functions, if there's some other way we could do it.  I think
we should explore the different design options so that we can verify for
the Forum that we've chosen the best one.

All,

Shall we schedule an RMA WG meeting some time soon?  Seems like it would be
good to get high bandwidth to go over these changes.  I also should give
the WG and update on the MPI_Aint_add session from the last Forum meeting.

 ~Jim.


On Fri, Jun 14, 2013 at 6:06 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:

>
> That's a fair point and I agree with it.  We should not add overhead to
> existing functionality to support this.  I guess the thought here is that
> for implementations that support fully asynchronous RMA communication, test
> or wait can essentially do the flush, with the caveat that test cannot
> block if someone else is holding the lock.
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
>
> "Barrett, Brian W" <bwbarre at sandia.gov> wrote:
>
> As an FYI, my problem with this proposal is two-fold:
>
> First, we need to deal with the fact that many of the calls are local
> today, meaning we need to fix some definitions, which is a big change
> (iflush/flush shouldn't have the same semantics).
>
> Second, the semantics of iflush (and friends) need lots of care. For
> example, allowing a communication event between iflush and wait would
> greatly hinder my implementation's performance when not using iflush.
>
> I understand the desire and like many of the non-blocking, but there are
> many places that we should balance non-blocking variants vs. performance
> loss...
>
> Brian
>
>
>
> Sent with Good (www.good.com)
>
>
> -----Original Message-----
> From: Pavan Balaji [balaji at mcs.anl.gov<mailto:balaji at mcs.anl.gov>]
> Sent: Friday, June 14, 2013 02:51 PM Mountain Standard Time
> To: mpi3-rma at lists.mpi-forum.org
> Subject: [EXTERNAL] Re: [Mpi3-rma] request-based ops
>
>
>
> On 06/14/2013 03:43 PM, Jim Dinan wrote:
> > Ahh, right, I had to miss that session at the Forum meeting.  If anyone
> > else is looking for them, these are the slides:
> >
> >
> http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf
> >
> > I was indeed forgetting about remote versus local completion and polling
> > on the request.  It sounds like this would definitely fill a gap in the
> > RMA interface.
>
> FYI, this was not meant to be an RMA proposal, since it touches blocking
> function calls in many chapters (e.g., COMM_ICONNECT and COMM_IACCEPT).
>
> I think I/O operations have a similar ticket as well.
>
> All these tickets need to be combined into a single nonblocking
> operations ticket.
>
>   -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-rma/attachments/20130615/e60e9872/attachment-0001.html>