[Mpi3-rma] [EXTERNAL] Re: request-based ops
Barrett, Brian W
bwbarre at sandia.gov
Fri Jun 14 16:00:49 CDT 2013
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...
Sent with Good (www.good.com)
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:
> 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
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mpiwg-rma