June 2015 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] cancel in standard
by Jeff Hammond 07 Jun '15

07 Jun '15

MPI 3.2 just to get rid of Cancel is worth it :-) Jeff Sent from my iPhone > On Jun 5, 2015, at 10:22 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Right now, there is no concept of "MPI-3.2" -- there's only MPI-3.1 errata and MPI-4.0. > > >> On Jun 5, 2015, at 12:47 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> >> I've changed the latter two to "MPI-next". >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> >> >> >> >> >> >> >>> On 6/5/15, 11:43 AM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote: >>> >>> The version information should probably be updated for the tickets that you are targeting for MPI 3.2 and MPI 4.0. Right now, they’re all MPI 3.1 errata. >>> >>> >>> >>> On June 5, 2015 at 11:29:58 AM, Balaji, Pavan (balaji(a)anl.gov<mailto:[email protected]>) wrote: >>> >>> FYI, here are the three tickets mentioned below. Feedback is appreciated. I'll pass this through the pt2pt working group, but I'm looking for general feedback at this point. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 >>> >>> >>> -- Pavan >>> >>> -- >>> Pavan Balaji >>> http://www.mcs.anl.gov/~balaji >>> >>> >>> >>> >>> >>> >>> >>>> On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> wrote: >>>> >>>> >>>> One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. >>>> >>>> For everyone's information, we are working on three tickets. >>>> >>>> 1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. >>>> >>>> 2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. >>>> >>>> 3. An MPI-4.0 ticket to remove send cancel. >>>> >>>> -- Pavan >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: >>>>> br/>>> Just a note: MPI__Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) >>>>> br/>>> -----Original Message----- < >>>>> From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp >>>>> Sent: Thursday, June 4, 2015 2:24 PM >>>>> To: Main MPI Forum mailing list >>>>> Subject: Re: [Mpi-forum] cancel in standard >>>>> br/>>> But the user did care about it, and theey decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). >>>>> br/>>> Bill < >>>>> br/>>>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>>>> br/>>>> What's the harm in letting a meessage that the user clearly does not br/>>>> care about sitt in a queue/buffer forever? I consider this an br/>>>> aacceptable consequence of a really stupid feature. >>>>>> br/>>>> Jeff < >>>>>> br/>>>>> On Wed, Jun 3, 2015 at 9:550 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>>>>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>>>>>> br/>>>>> Bill < >>>>>>> br/>>>>>> On Jun 3, 2015, att 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>>>> br/>>>>>> br/>>>>>> [[Cc'ed the Forum] >>>>>>>> br/>>>>>> This wording haas been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>>>>>> br/>>>>>> The consensus ffrom MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>>>>>> br/>>>>>> You could try tto weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>>>>>> br/>>>>>> -- Pavan < >>>>>>>> br/>>>>>> br/>>>>>> br/>>>>>> br/>>>>>>> On 6/3/15, 7:05 PM, ""Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>>>>> br/>>>>>>> What liines in the standard support the interpretation that "a br/>>>t;>>>> message that will not be successfully matched, must be cancelable"? >>>>>>>>> br/>>>>>>> This iss what I found, and it doesn't support the stricter interpretation. >>>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> ""If a >>>>>>>>> send is marked for cancellation, then it must be the case that br/>>>>>>> either the send ccompletes normally, in which case the message sent br/>>>>&ggt;>> was received at the destination process, or that the send is br/>>>>>>> successfully cancelled, in which case noo part of the message was br/>>>>>>> received at thhe destination. Then, any matching receive has to be br/>>>>;>>> satisfied by another send." >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>> br/>>>>> ________________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> br/>>>> br/>>>> br/>>>> -- < >>>>>> Jeff Hammond >>>>>> jeff.science(a)gmail.com >>>>>> http://jeffhammond.github.io/ >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> br/>>> ________________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> Intel GmbH >>>>> Dornacher Strasse 1 >>>>> 85622 Feldkirchen/Muenchen, Deutschland >>>>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>>>> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk >>>>> Registergericht: Muenchen HRB 47456 >>>>> Ust.-IdNr./VAT Registration No.: DE129385895 >>>>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >>>>> br/>>> ________________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Schulz Martin 07 Jun '15

07 Jun '15

I think we should avoid MPI-<next>, at least for now. We tried to phase this out when we decided on MPI 3.1 and I actually thought we removed it, but I guess not. For now, at least IMHO, it would be good to keep every active ticket either in MPI 3.1 errata or MPI 4.0. This will make it much easier if we actually go through with the conversion to git and pull requests. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 6/5/15, 10:22 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >Right now, there is no concept of "MPI-3.2" -- there's only MPI-3.1 >errata and MPI-4.0. > > >> On Jun 5, 2015, at 12:47 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> >> I've changed the latter two to "MPI-next". >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> >> >> >> >> >> >> >> On 6/5/15, 11:43 AM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote: >> >>> The version information should probably be updated for the tickets >>>that you are targeting for MPI 3.2 and MPI 4.0. Right now, they¹re all >>>MPI 3.1 errata. >>> >>> >>> >>> On June 5, 2015 at 11:29:58 AM, Balaji, Pavan >>>(balaji(a)anl.gov<mailto:[email protected]>) wrote: >>> >>> FYI, here are the three tickets mentioned below. Feedback is >>>appreciated. I'll pass this through the pt2pt working group, but I'm >>>looking for general feedback at this point. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 >>> >>> >>> -- Pavan >>> >>> -- >>> Pavan Balaji >>> http://www.mcs.anl.gov/~balaji >>> >>> >>> >>> >>> >>> >>> >>> On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" >>><mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> >>>wrote: >>> >>>> >>>> One of the main reasons cancel send was introduced was for symmetry, >>>>since there were cancel receives too. But that argument has gone out >>>>the window with NBC, RMA and I/O requests which are all not cancelable. >>>> >>>> For everyone's information, we are working on three tickets. >>>> >>>> 1. An MPI-3.1 errata ticket to clarify the wording in the MPI >>>>standard as to what cancel send must do. This will also remove some >>>>incorrect wording in the standard with respect to the behavior of >>>>wait/test after a failed cancelation. >>>> >>>> 2. An MPI-3.2 ticket to deprecate send cancel citing all the >>>>complexities in implementing it efficiently. More importantly the cost >>>>of supporting send cancel on non-cancel operations. >>>> >>>> 3. An MPI-4.0 ticket to remove send cancel. >>>> >>>> -- Pavan >>>> >>>> Sent from my iPhone >>>> >>>>> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander >>>>><alexander.supalov(a)intel.com> wrote: >>>>> br/>>> Just a note: MPI__Cancel would be next to MPI_ANY SOURCE to >>>>>go had one introduced assertions. :) >>>>> br/>>> -----Original Message----- < >>>>> From: mpi-forum [mailto:[email protected]] On >>>>>Behalf Of William Gropp >>>>> Sent: Thursday, June 4, 2015 2:24 PM >>>>> To: Main MPI Forum mailing list >>>>> Subject: Re: [Mpi-forum] cancel in standard >>>>> br/>>> But the user did care about it, and theey decided to cancel >>>>>it. It may not be one message, but one per iteration. And the >>>>>semantics is clear (even if the standard's language isn't). >>>>> br/>>> Bill < >>>>> br/>>>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond >>>>><jeff.science(a)gmail.com> wrote: >>>>>> br/>>>> What's the harm in letting a meessage that the user clearly >>>>>>does not br/>>>> care about sitt in a queue/buffer forever? I >>>>>>consider this an br/>>>> aacceptable consequence of a really stupid >>>>>>feature. >>>>>> br/>>>> Jeff < >>>>>> br/>>>>> On Wed, Jun 3, 2015 at 9:550 PM, William Gropp >>>>>><wgropp(a)illinois.edu> wrote: >>>>>>> Pavan is correct about the intent, and we could make this more >>>>>>>precise. The basic requirement is that a message is *guaranteed* to >>>>>>>either be canceled (on send) or received. Sitting in a queue or >>>>>>>buffer somewhere does not count. >>>>>>> br/>>>>> Bill < >>>>>>> br/>>>>>> On Jun 3, 2015, att 7:19 PM, Balaji, Pavan >>>>>>><balaji(a)anl.gov> wrote: >>>>>>>> br/>>>>>> br/>>>>>> [[Cc'ed the Forum] >>>>>>>> br/>>>>>> This wording haas been debated many times at the Forum. >>>>>>>>Specifically, the "completes normally" and "received at the >>>>>>>>destination" pieces are ambiguous. For instance, if the data is >>>>>>>>copied into a bounce buffer, the send would complete normally, but >>>>>>>>that does not mean that there is a receive posted for that data. >>>>>>>>In this case, it would be the user's responsibility to post a >>>>>>>>corresponding receive. If the MPI implementation does not have a >>>>>>>>bounce buffer (e.g., for large messages), "received at the >>>>>>>>destination" could mean into an unexpected buffer, not necessarily >>>>>>>>a user buffer. >>>>>>>> br/>>>>>> The consensus ffrom MPI-1 veterans (Marc, Bill, etc.) >>>>>>>>during the last discussion was that if the application does not >>>>>>>>post a receive, then it is guaranteed that the send should be >>>>>>>>cancelable. At least that was the intent. The wording, of course, >>>>>>>>is too vague for such a definition. >>>>>>>> br/>>>>>> You could try tto weaken that interpretation and say >>>>>>>>that if the MPI implementation is not able to cancel a send >>>>>>>>operation, then the user is responsible for posting a matching >>>>>>>>receive to receive that data. Irrespective of which interpretation >>>>>>>>we go with, I think it is important to clarify it in the standard. >>>>>>>>Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for >>>>>>>>MPI-4? Do you want to create a ticket? >>>>>>>> br/>>>>>> -- Pavan < >>>>>>>> br/>>>>>> br/>>>>>> br/>>>>>> br/>>>>>>> On 6/3/15, 7:05 PM, >>>>>>>>""Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>>>>> br/>>>>>>> What liines in the standard support the >>>>>>>>>interpretation that "a br/>>>t;>>>> message that will not be >>>>>>>>>successfully matched, must be cancelable"? >>>>>>>>> br/>>>>>>> This iss what I found, and it doesn't support the >>>>>>>>>stricter interpretation. >>>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> >>>>>>>>>br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> ""If a >>>>>>>>> send is marked for cancellation, then it must be the case that >>>>>>>>>br/>>>>>>> either the send ccompletes normally, in which case the >>>>>>>>>message sent br/>>>>&ggt;>> was received at the destination >>>>>>>>>process, or that the send is br/>>>>>>> successfully cancelled, >>>>>>>>>in which case noo part of the message was br/>>>>>>> received at >>>>>>>>>thhe destination. Then, any matching receive has to be >>>>>>>>>br/>>>>;>>> satisfied by another send." >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>> br/>>>>> ________________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> br/>>>> br/>>>> br/>>>> -- < >>>>>> Jeff Hammond >>>>>> jeff.science(a)gmail.com >>>>>> http://jeffhammond.github.io/ >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> br/>>> ________________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> Intel GmbH >>>>> Dornacher Strasse 1 >>>>> 85622 Feldkirchen/Muenchen, Deutschland >>>>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>>>> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas >>>>>Lusk >>>>> Registergericht: Muenchen HRB 47456 >>>>> Ust.-IdNr./VAT Registration No.: DE129385895 >>>>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >>>>> br/>>> ________________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Jeff Squyres (jsquyres) 05 Jun '15

05 Jun '15

Right now, there is no concept of "MPI-3.2" -- there's only MPI-3.1 errata and MPI-4.0. > On Jun 5, 2015, at 12:47 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > I've changed the latter two to "MPI-next". > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > > > > > > > On 6/5/15, 11:43 AM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote: > >> The version information should probably be updated for the tickets that you are targeting for MPI 3.2 and MPI 4.0. Right now, they’re all MPI 3.1 errata. >> >> >> >> On June 5, 2015 at 11:29:58 AM, Balaji, Pavan (balaji(a)anl.gov<mailto:[email protected]>) wrote: >> >> FYI, here are the three tickets mentioned below. Feedback is appreciated. I'll pass this through the pt2pt working group, but I'm looking for general feedback at this point. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 >> >> >> -- Pavan >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> >> >> >> >> >> >> >> On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> wrote: >> >>> >>> One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. >>> >>> For everyone's information, we are working on three tickets. >>> >>> 1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. >>> >>> 2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. >>> >>> 3. An MPI-4.0 ticket to remove send cancel. >>> >>> -- Pavan >>> >>> Sent from my iPhone >>> >>>> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: >>>> br/>>> Just a note: MPI__Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) >>>> br/>>> -----Original Message----- < >>>> From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp >>>> Sent: Thursday, June 4, 2015 2:24 PM >>>> To: Main MPI Forum mailing list >>>> Subject: Re: [Mpi-forum] cancel in standard >>>> br/>>> But the user did care about it, and theey decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). >>>> br/>>> Bill < >>>> br/>>>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>>> br/>>>> What's the harm in letting a meessage that the user clearly does not br/>>>> care about sitt in a queue/buffer forever? I consider this an br/>>>> aacceptable consequence of a really stupid feature. >>>>> br/>>>> Jeff < >>>>> br/>>>>> On Wed, Jun 3, 2015 at 9:550 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>>>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>>>>> br/>>>>> Bill < >>>>>> br/>>>>>> On Jun 3, 2015, att 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>>> br/>>>>>> br/>>>>>> [[Cc'ed the Forum] >>>>>>> br/>>>>>> This wording haas been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>>>>> br/>>>>>> The consensus ffrom MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>>>>> br/>>>>>> You could try tto weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>>>>> br/>>>>>> -- Pavan < >>>>>>> br/>>>>>> br/>>>>>> br/>>>>>> br/>>>>>>> On 6/3/15, 7:05 PM, ""Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>>>> br/>>>>>>> What liines in the standard support the interpretation that "a br/>>>t;>>>> message that will not be successfully matched, must be cancelable"? >>>>>>>> br/>>>>>>> This iss what I found, and it doesn't support the stricter interpretation. >>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> ""If a >>>>>>>> send is marked for cancellation, then it must be the case that br/>>>>>>> either the send ccompletes normally, in which case the message sent br/>>>>&ggt;>> was received at the destination process, or that the send is br/>>>>>>> successfully cancelled, in which case noo part of the message was br/>>>>>>> received at thhe destination. Then, any matching receive has to be br/>>>>;>>> satisfied by another send." >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> br/>>>>> ________________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> br/>>>> br/>>>> br/>>>> -- < >>>>> Jeff Hammond >>>>> jeff.science(a)gmail.com >>>>> http://jeffhammond.github.io/ >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> br/>>> ________________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> Intel GmbH >>>> Dornacher Strasse 1 >>>> 85622 Feldkirchen/Muenchen, Deutschland >>>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>>> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk >>>> Registergericht: Muenchen HRB 47456 >>>> Ust.-IdNr./VAT Registration No.: DE129385895 >>>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >>>> br/>>> ________________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 05 Jun '15

05 Jun '15

I've changed the latter two to "MPI-next". -- Pavan Balaji http://www.mcs.anl.gov/~balaji On 6/5/15, 11:43 AM, "Bland, Wesley" <wesley.bland(a)intel.com> wrote: >The version information should probably be updated for the tickets that you are targeting for MPI 3.2 and MPI 4.0. Right now, they’re all MPI 3.1 errata. > > > >On June 5, 2015 at 11:29:58 AM, Balaji, Pavan (balaji(a)anl.gov<mailto:[email protected]>) wrote: > >FYI, here are the three tickets mentioned below. Feedback is appreciated. I'll pass this through the pt2pt working group, but I'm looking for general feedback at this point. > >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 > >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 > >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 > > >-- Pavan > >-- >Pavan Balaji >http://www.mcs.anl.gov/~balaji > > > > > > > >On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> wrote: > >> >>One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. >> >>For everyone's information, we are working on three tickets. >> >>1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. >> >>2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. >> >>3. An MPI-4.0 ticket to remove send cancel. >> >> -- Pavan >> >>Sent from my iPhone >> >>> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: >>> br/>>> Just a note: MPI__Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) >>> br/>>> -----Original Message----- < >>> From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp >>> Sent: Thursday, June 4, 2015 2:24 PM >>> To: Main MPI Forum mailing list >>> Subject: Re: [Mpi-forum] cancel in standard >>> br/>>> But the user did care about it, and theey decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). >>> br/>>> Bill < >>> br/>>>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> br/>>>> What's the harm in letting a meessage that the user clearly does not br/>>>> care about sitt in a queue/buffer forever? I consider this an br/>>>> aacceptable consequence of a really stupid feature. >>>> br/>>>> Jeff < >>>> br/>>>>> On Wed, Jun 3, 2015 at 9:550 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>>>> br/>>>>> Bill < >>>>> br/>>>>>> On Jun 3, 2015, att 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>> br/>>>>>> br/>>>>>> [[Cc'ed the Forum] >>>>>> br/>>>>>> This wording haas been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>>>> br/>>>>>> The consensus ffrom MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>>>> br/>>>>>> You could try tto weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>>>> br/>>>>>> -- Pavan < >>>>>> br/>>>>>> br/>>>>>> br/>>>>>> br/>>>>>>> On 6/3/15, 7:05 PM, ""Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>>> br/>>>>>>> What liines in the standard support the interpretation that "a br/>>>t;>>>> message that will not be successfully matched, must be cancelable"? >>>>>>> br/>>>>>>> This iss what I found, and it doesn't support the stricter interpretation. >>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> ""If a >>>>>>> send is marked for cancellation, then it must be the case that br/>>>>>>> either the send ccompletes normally, in which case the message sent br/>>>>&ggt;>> was received at the destination process, or that the send is br/>>>>>>> successfully cancelled, in which case noo part of the message was br/>>>>>>> received at thhe destination. Then, any matching receive has to be br/>>>>;>>> satisfied by another send." >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> br/>>>>> ________________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> br/>>>> br/>>>> br/>>>> -- < >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>>> http://jeffhammond.github.io/ >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> br/>>> ________________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> Intel GmbH >>> Dornacher Strasse 1 >>> 85622 Feldkirchen/Muenchen, Deutschland >>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk >>> Registergericht: Muenchen HRB 47456 >>> Ust.-IdNr./VAT Registration No.: DE129385895 >>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >>> br/>>> ________________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>_______________________________________________ >>mpi-forum mailing list >>mpi-forum(a)lists.mpi-forum.org >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Bland, Wesley 05 Jun '15

05 Jun '15

The version information should probably be updated for the tickets that you are targeting for MPI 3.2 and MPI 4.0. Right now, they’re all MPI 3.1 errata. On June 5, 2015 at 11:29:58 AM, Balaji, Pavan (balaji(a)anl.gov<mailto:[email protected]>) wrote: FYI, here are the three tickets mentioned below. Feedback is appreciated. I'll pass this through the pt2pt working group, but I'm looking for general feedback at this point. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> wrote: > >One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. > >For everyone's information, we are working on three tickets. > >1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. > >2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. > >3. An MPI-4.0 ticket to remove send cancel. > > -- Pavan > >Sent from my iPhone > >> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: >> br/>>> Just a note: MPI__Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) >> br/>>> -----Original Message----- < >> From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp >> Sent: Thursday, June 4, 2015 2:24 PM >> To: Main MPI Forum mailing list >> Subject: Re: [Mpi-forum] cancel in standard >> br/>>> But the user did care about it, and theey decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). >> br/>>> Bill < >> br/>>>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> br/>>>> What's the harm in letting a meessage that the user clearly does not br/>>>> care about sitt in a queue/buffer forever? I consider this an br/>>>> aacceptable consequence of a really stupid feature. >>> br/>>>> Jeff < >>> br/>>>>> On Wed, Jun 3, 2015 at 9:550 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>>> br/>>>>> Bill < >>>> br/>>>>>> On Jun 3, 2015, att 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> br/>>>>>> br/>>>>>> [[Cc'ed the Forum] >>>>> br/>>>>>> This wording haas been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>>> br/>>>>>> The consensus ffrom MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>>> br/>>>>>> You could try tto weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>>> br/>>>>>> -- Pavan < >>>>> br/>>>>>> br/>>>>>> br/>>>>>> br/>>>>>>> On 6/3/15, 7:05 PM, ""Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>> br/>>>>>>> What liines in the standard support the interpretation that "a br/>>>t;>>>> message that will not be successfully matched, must be cancelable"? >>>>>> br/>>>>>>> This iss what I found, and it doesn't support the stricter interpretation. >>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> br/>>>>>>> ""If a >>>>>> send is marked for cancellation, then it must be the case that br/>>>>>>> either the send ccompletes normally, in which case the message sent br/>>>>&ggt;>> was received at the destination process, or that the send is br/>>>>>>> successfully cancelled, in which case noo part of the message was br/>>>>>>> received at thhe destination. Then, any matching receive has to be br/>>>>;>>> satisfied by another send." >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> br/>>>>> ________________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> br/>>>> br/>>>> br/>>>> -- < >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> br/>>> ________________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 >> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >> br/>>> ________________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 05 Jun '15

05 Jun '15

FYI, here are the three tickets mentioned below. Feedback is appreciated. I'll pass this through the pt2pt working group, but I'm looking for general feedback at this point. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/478 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/479 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/480 -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji On 6/5/15, 7:08 AM, "mpi-forum on behalf of Balaji, Pavan" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of balaji(a)anl.gov> wrote: > >One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. > >For everyone's information, we are working on three tickets. > >1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. > >2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. > >3. An MPI-4.0 ticket to remove send cancel. > > -- Pavan > >Sent from my iPhone > >> On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: >> >> Just a note: MPI_Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) >> >> -----Original Message----- >> From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp >> Sent: Thursday, June 4, 2015 2:24 PM >> To: Main MPI Forum mailing list >> Subject: Re: [Mpi-forum] cancel in standard >> >> But the user did care about it, and they decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). >> >> Bill >> >>> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> What's the harm in letting a message that the user clearly does not >>> care about sit in a queue/buffer forever? I consider this an >>> acceptable consequence of a really stupid feature. >>> >>> Jeff >>> >>>> On Wed, Jun 3, 2015 at 9:50 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>>> >>>> Bill >>>> >>>>> On Jun 3, 2015, at 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>> >>>>> [Cc'ed the Forum] >>>>> >>>>> This wording has been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>>> >>>>> The consensus from MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>>> >>>>> You could try to weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>>> >>>>> -- Pavan >>>>> >>>>> >>>>> >>>>> >>>>>> On 6/3/15, 7:05 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>>> >>>>>> What lines in the standard support the interpretation that "a >>>>>> message that will not be successfully matched, must be cancelable"? >>>>>> >>>>>> This is what I found, and it doesn't support the stricter interpretation. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> "If a >>>>>> send is marked for cancellation, then it must be the case that >>>>>> either the send completes normally, in which case the message sent >>>>>> was received at the destination process, or that the send is >>>>>> successfully cancelled, in which case no part of the message was >>>>>> received at the destination. Then, any matching receive has to be >>>>>> satisfied by another send." >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 >> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Balaji, Pavan 05 Jun '15

05 Jun '15

One of the main reasons cancel send was introduced was for symmetry, since there were cancel receives too. But that argument has gone out the window with NBC, RMA and I/O requests which are all not cancelable. For everyone's information, we are working on three tickets. 1. An MPI-3.1 errata ticket to clarify the wording in the MPI standard as to what cancel send must do. This will also remove some incorrect wording in the standard with respect to the behavior of wait/test after a failed cancelation. 2. An MPI-3.2 ticket to deprecate send cancel citing all the complexities in implementing it efficiently. More importantly the cost of supporting send cancel on non-cancel operations. 3. An MPI-4.0 ticket to remove send cancel. -- Pavan Sent from my iPhone > On Jun 5, 2015, at 3:16 AM, Supalov, Alexander <alexander.supalov(a)intel.com> wrote: > > Just a note: MPI_Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) > > -----Original Message----- > From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp > Sent: Thursday, June 4, 2015 2:24 PM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] cancel in standard > > But the user did care about it, and they decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). > > Bill > >> On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> What's the harm in letting a message that the user clearly does not >> care about sit in a queue/buffer forever? I consider this an >> acceptable consequence of a really stupid feature. >> >> Jeff >> >>> On Wed, Jun 3, 2015 at 9:50 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >>> >>> Bill >>> >>>> On Jun 3, 2015, at 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>> >>>> [Cc'ed the Forum] >>>> >>>> This wording has been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>>> >>>> The consensus from MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>>> >>>> You could try to weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>>> >>>> -- Pavan >>>> >>>> >>>> >>>> >>>>> On 6/3/15, 7:05 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>>>> >>>>> What lines in the standard support the interpretation that "a >>>>> message that will not be successfully matched, must be cancelable"? >>>>> >>>>> This is what I found, and it doesn't support the stricter interpretation. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> "If a >>>>> send is marked for cancellation, then it must be the case that >>>>> either the send completes normally, in which case the message sent >>>>> was received at the destination process, or that the send is >>>>> successfully cancelled, in which case no part of the message was >>>>> received at the destination. Then, any matching receive has to be >>>>> satisfied by another send." >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] cancel in standard
by Supalov, Alexander 05 Jun '15

05 Jun '15

Just a note: MPI_Cancel would be next to MPI_ANY SOURCE to go had one introduced assertions. :) -----Original Message----- From: mpi-forum [mailto:[email protected]] On Behalf Of William Gropp Sent: Thursday, June 4, 2015 2:24 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] cancel in standard But the user did care about it, and they decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard's language isn't). Bill On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > What's the harm in letting a message that the user clearly does not > care about sit in a queue/buffer forever? I consider this an > acceptable consequence of a really stupid feature. > > Jeff > > On Wed, Jun 3, 2015 at 9:50 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >> >> Bill >> >> On Jun 3, 2015, at 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> >>> [Cc'ed the Forum] >>> >>> This wording has been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>> >>> The consensus from MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>> >>> You could try to weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>> >>> -- Pavan >>> >>> >>> >>> >>> On 6/3/15, 7:05 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>> >>>> What lines in the standard support the interpretation that "a >>>> message that will not be successfully matched, must be cancelable"? >>>> >>>> This is what I found, and it doesn't support the stricter interpretation. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> "If a >>>> send is marked for cancellation, then it must be the case that >>>> either the send completes normally, in which case the message sent >>>> was received at the destination process, or that the send is >>>> successfully cancelled, in which case no part of the message was >>>> received at the destination. Then, any matching receive has to be >>>> satisfied by another send." >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

MPI-3.1 has passed!
by Jeff Squyres (jsquyres) 04 Jun '15

04 Jun '15

With a vote of: 23 for 0 against 1 abstain MPI-3.1 has passed. The document is already live on the web: http://www.mpi-forum.org/docs/docs.html Congratulations! -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ [cid:[email protected]]

1 0

Re: [Mpi-forum] cancel in standard
by William Gropp 04 Jun '15

04 Jun '15

But the user did care about it, and they decided to cancel it. It may not be one message, but one per iteration. And the semantics is clear (even if the standard’s language isn’t). Bill On Jun 3, 2015, at 10:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > What's the harm in letting a message that the user clearly does not > care about sit in a queue/buffer forever? I consider this an > acceptable consequence of a really stupid feature. > > Jeff > > On Wed, Jun 3, 2015 at 9:50 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> Pavan is correct about the intent, and we could make this more precise. The basic requirement is that a message is *guaranteed* to either be canceled (on send) or received. Sitting in a queue or buffer somewhere does not count. >> >> Bill >> >> On Jun 3, 2015, at 7:19 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> >>> [Cc'ed the Forum] >>> >>> This wording has been debated many times at the Forum. Specifically, the "completes normally" and "received at the destination" pieces are ambiguous. For instance, if the data is copied into a bounce buffer, the send would complete normally, but that does not mean that there is a receive posted for that data. In this case, it would be the user's responsibility to post a corresponding receive. If the MPI implementation does not have a bounce buffer (e.g., for large messages), "received at the destination" could mean into an unexpected buffer, not necessarily a user buffer. >>> >>> The consensus from MPI-1 veterans (Marc, Bill, etc.) during the last discussion was that if the application does not post a receive, then it is guaranteed that the send should be cancelable. At least that was the intent. The wording, of course, is too vague for such a definition. >>> >>> You could try to weaken that interpretation and say that if the MPI implementation is not able to cancel a send operation, then the user is responsible for posting a matching receive to receive that data. Irrespective of which interpretation we go with, I think it is important to clarify it in the standard. Perhaps an MPI-3.1 errata or MPI-3.2 change instead of waiting for MPI-4? Do you want to create a ticket? >>> >>> -- Pavan >>> >>> >>> >>> >>> On 6/3/15, 7:05 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>> >>>> What lines in the standard support the interpretation that “a message that >>>> will not be successfully matched, must be cancelable”? >>>> >>>> This is what I found, and it doesn’t support the stricter interpretation. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> "If a >>>> send is marked for cancellation, then it must be the case that either the >>>> send completes >>>> normally, in which case the message sent was received at the destination >>>> process, or that >>>> the send is successfully cancelled, in which case no part of the message >>>> was received at the >>>> destination. Then, any matching receive has to be satisfied by another >>>> send." >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0