[Mpi3-rma] request-based ops

[Jeff Hammond]

Yes, I was making a disingenuous argument to push back against the
fallacy that iwin_flush is not required.

Jeff

On Fri, Jun 14, 2013 at 10:25 AM, Jim Dinan <james.dinan at gmail.com> wrote:
> Hey now, blocking doesn't mean that MPI /must/ block, it only means that it
> /can/ block.  Blocking and synchronizing are certainly not the same; Ssend
> synchronizes, which is a stronger semantic than blocking.
>
>  ~Jim.
>
>
> On Wed, Jun 12, 2013 at 5:07 PM, Jeff Hammond <jhammond at alcf.anl.gov> wrote:
>>
>> Sure, let's separate these issues.  I think Pirate RMA (RRPUT,
>> RRACCUMULATE and RRRGET_ACCUMULATE) is a more _local_ solution in the
>> MPI standard sense :-)
>>
>> SEND is also a nonblocking operation because the implementation can
>> always buffer the data and return before the remote RECV is posted.
>> Only SSEND is blocking if one asserts that blocking is equivalent to
>> "requires remote agency to complete".
>>
>> So basically, I completely agree with the Forum back-pushers that
>> IWIN_FLUSH etc. are as useful as ISEND.
>>
>> Jeff
>>
>> On Wed, Jun 12, 2013 at 4:58 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
>> >
>> > The push-back at the Forum was that WIN_FLUSH and WIN_UNLOCK are local
>> > operations (in MPI's definition of local), so they are already
>> > nonblocking.
>> > I was not at the Forum.  I pointed out to Wesley after he returned that
>> > they
>> > are only local in the simple case where no one else is holding the lock.
>> > Otherwise they are not.
>> >
>> > Further, the proposal is not only about WIN_FLUSH and WIN_UNLOCK.  It
>> > was
>> > for a long list of blocking functions: COMM_ACCEPT, COMM_CONNECT,
>> > WIN_FENCE,
>> > WIN_COMPLETE, WIN_WAIT, WIN_UNLOCK, WIN_FLUSH, WIN_FLUSH_LOCAL,
>> > WIN_FLUSH_ALL, WIN_FLUSH_LOCAL_ALL, ...  The point was that MPI should
>> > deal
>> > with concepts, not specific function exceptions. Nonblocking
>> > communication
>> > is one such concept, and it should be valid for all operations (that are
>> > not
>> > local).
>> >
>> > FWIW, my proposal was only to add nonblocking variants to blocking
>> > calls.
>> > Adding extra per-op remote completion requests is a separate issue and
>> > should not be mixed with this.  I personally think it's useful (in fact,
>> > my
>> > original proposal for RPUT/RGET equivalents had it), but that's still a
>> > separate issue.
>> >
>> >  -- Pavan
>> >
>> >
>> > On 06/12/2013 09:41 AM, Jeff Hammond wrote:
>> >>
>> >> So Wes was telling me about IWIN_FLUSH yesterday (this function is a
>> >> great idea, btw) and the alternative of adding double-request RPUT and
>> >> RACCUMULATE that provide a request for both local and remote
>> >> completion.  By induction, this would imply a triple-request
>> >> RGET_ACCUMULATE operation, which I also think is a good idea.  It's
>> >> really silly to have to wait for the result buffer to be ready to
>> >> reuse the origin buffer in RGET_ACCUMULATE.  It seems that many
>> >> implementations will be able to send the entire origin buffer a
>> >> nontrivial amount of time before the result comes back, particularly
>> >> if the remote side doesn't have hardware-based progress and the data
>> >> has to wait in a network buffer.
>> >>
>> >> I'm sorry that I missed the last day of the Forum in San Jose.  I
>> >> didn't know these operations were on the table.  They sound like a
>> >> great idea to me.
>> >>
>> >> Jeff
>> >>
>> >
>> > --
>> > Pavan Balaji
>> > http://www.mcs.anl.gov/~balaji
>>
>>
>>
>> --
>> Jeff Hammond
>> Argonne Leadership Computing Facility
>> University of Chicago Computation Institute
>> jhammond at alcf.anl.gov / (630) 252-5381
>> http://www.linkedin.com/in/jeffhammond
>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
>> ALCF docs: http://www.alcf.anl.gov/user-guides
>> _______________________________________________
>> 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



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
ALCF docs: http://www.alcf.anl.gov/user-guides