<div dir="ltr">Ahh, right, I had to miss that session at the Forum meeting.  If anyone else is looking for them, these are the slides:<div><br></div><div><a href="http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf">http://meetings.mpi-forum.org/secretary/2013/06/slides/2013-06-06-Nonblocking-Operations.pdf</a></div>
<div><br></div><div>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.</div><div><br></div><div style> ~Jim.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 12:56 PM, Jeff Hammond <span dir="ltr"><<a href="mailto:jhammond@alcf.anl.gov" target="_blank">jhammond@alcf.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"The completion of an MPI_RACCUMULATE operation indicates that the<br>
origin buffer is free to be updated. It does not indicate that the<br>
operation has completed at the target window."<br>
<br>
How does waiting on this request give me the same behavior as IWIN_FLUSH?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Jun 14, 2013 at 12:23 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
> Jeff,<br>
><br>
> How would iwin_flush be different in practice from doing nothing?  I can<br>
> give you a trivial implementation that does nothing until you wait on the<br>
> request, at which point I call blocking win_flush.  With my implementor hat<br>
> on, I would view this function as a performance hint that indicates to the<br>
> implementation that you will want to complete all operations thus far and<br>
> none after.  Given a high quality implementation that actually makes<br>
> background progress on one-sided communications, this should be unnecessary<br>
> and I would probably implement it as above.  If you want to only complete<br>
> specific operations, the request generating functions are available.<br>
><br>
>  ~Jim.<br>
><br>
><br>
><br>
> On Fri, Jun 14, 2013 at 11:09 AM, Jeff Hammond <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>><br>
> wrote:<br>
>><br>
>> Yes, I was making a disingenuous argument to push back against the<br>
>> fallacy that iwin_flush is not required.<br>
>><br>
>> Jeff<br>
>><br>
>> On Fri, Jun 14, 2013 at 10:25 AM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
>> > Hey now, blocking doesn't mean that MPI /must/ block, it only means that<br>
>> > it<br>
>> > /can/ block.  Blocking and synchronizing are certainly not the same;<br>
>> > Ssend<br>
>> > synchronizes, which is a stronger semantic than blocking.<br>
>> ><br>
>> >  ~Jim.<br>
>> ><br>
>> ><br>
>> > On Wed, Jun 12, 2013 at 5:07 PM, Jeff Hammond <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Sure, let's separate these issues.  I think Pirate RMA (RRPUT,<br>
>> >> RRACCUMULATE and RRRGET_ACCUMULATE) is a more _local_ solution in the<br>
>> >> MPI standard sense :-)<br>
>> >><br>
>> >> SEND is also a nonblocking operation because the implementation can<br>
>> >> always buffer the data and return before the remote RECV is posted.<br>
>> >> Only SSEND is blocking if one asserts that blocking is equivalent to<br>
>> >> "requires remote agency to complete".<br>
>> >><br>
>> >> So basically, I completely agree with the Forum back-pushers that<br>
>> >> IWIN_FLUSH etc. are as useful as ISEND.<br>
>> >><br>
>> >> Jeff<br>
>> >><br>
>> >> On Wed, Jun 12, 2013 at 4:58 PM, Pavan Balaji <<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> > The push-back at the Forum was that WIN_FLUSH and WIN_UNLOCK are<br>
>> >> > local<br>
>> >> > operations (in MPI's definition of local), so they are already<br>
>> >> > nonblocking.<br>
>> >> > I was not at the Forum.  I pointed out to Wesley after he returned<br>
>> >> > that<br>
>> >> > they<br>
>> >> > are only local in the simple case where no one else is holding the<br>
>> >> > lock.<br>
>> >> > Otherwise they are not.<br>
>> >> ><br>
>> >> > Further, the proposal is not only about WIN_FLUSH and WIN_UNLOCK.  It<br>
>> >> > was<br>
>> >> > for a long list of blocking functions: COMM_ACCEPT, COMM_CONNECT,<br>
>> >> > WIN_FENCE,<br>
>> >> > WIN_COMPLETE, WIN_WAIT, WIN_UNLOCK, WIN_FLUSH, WIN_FLUSH_LOCAL,<br>
>> >> > WIN_FLUSH_ALL, WIN_FLUSH_LOCAL_ALL, ...  The point was that MPI<br>
>> >> > should<br>
>> >> > deal<br>
>> >> > with concepts, not specific function exceptions. Nonblocking<br>
>> >> > communication<br>
>> >> > is one such concept, and it should be valid for all operations (that<br>
>> >> > are<br>
>> >> > not<br>
>> >> > local).<br>
>> >> ><br>
>> >> > FWIW, my proposal was only to add nonblocking variants to blocking<br>
>> >> > calls.<br>
>> >> > Adding extra per-op remote completion requests is a separate issue<br>
>> >> > and<br>
>> >> > should not be mixed with this.  I personally think it's useful (in<br>
>> >> > fact,<br>
>> >> > my<br>
>> >> > original proposal for RPUT/RGET equivalents had it), but that's still<br>
>> >> > a<br>
>> >> > separate issue.<br>
>> >> ><br>
>> >> >  -- Pavan<br>
>> >> ><br>
>> >> ><br>
>> >> > On 06/12/2013 09:41 AM, Jeff Hammond wrote:<br>
>> >> >><br>
>> >> >> So Wes was telling me about IWIN_FLUSH yesterday (this function is a<br>
>> >> >> great idea, btw) and the alternative of adding double-request RPUT<br>
>> >> >> and<br>
>> >> >> RACCUMULATE that provide a request for both local and remote<br>
>> >> >> completion.  By induction, this would imply a triple-request<br>
>> >> >> RGET_ACCUMULATE operation, which I also think is a good idea.  It's<br>
>> >> >> really silly to have to wait for the result buffer to be ready to<br>
>> >> >> reuse the origin buffer in RGET_ACCUMULATE.  It seems that many<br>
>> >> >> implementations will be able to send the entire origin buffer a<br>
>> >> >> nontrivial amount of time before the result comes back, particularly<br>
>> >> >> if the remote side doesn't have hardware-based progress and the data<br>
>> >> >> has to wait in a network buffer.<br>
>> >> >><br>
>> >> >> I'm sorry that I missed the last day of the Forum in San Jose.  I<br>
>> >> >> didn't know these operations were on the table.  They sound like a<br>
>> >> >> great idea to me.<br>
>> >> >><br>
>> >> >> Jeff<br>
>> >> >><br>
>> >> ><br>
>> >> > --<br>
>> >> > Pavan Balaji<br>
>> >> > <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Jeff Hammond<br>
>> >> Argonne Leadership Computing Facility<br>
>> >> University of Chicago Computation Institute<br>
>> >> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / (630) 252-5381<br>
>> >> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
>> >> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
>> >> ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
>> >> _______________________________________________<br>
>> >> mpi3-rma mailing list<br>
>> >> <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
>> >> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > mpi3-rma mailing list<br>
>> > <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
>> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jeff Hammond<br>
>> Argonne Leadership Computing Facility<br>
>> University of Chicago Computation Institute<br>
>> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / (630) 252-5381<br>
>> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
>> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
>> ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
>> _______________________________________________<br>
>> mpi3-rma mailing list<br>
>> <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mpi3-rma mailing list<br>
> <a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
<br>
<br>
<br>
--<br>
Jeff Hammond<br>
Argonne Leadership Computing Facility<br>
University of Chicago Computation Institute<br>
<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / (630) 252-5381<br>
<a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
<a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
_______________________________________________<br>
mpi3-rma mailing list<br>
<a href="mailto:mpi3-rma@lists.mpi-forum.org">mpi3-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma</a><br>
</div></div></blockquote></div><br></div>