- mpiwg-p2p - mailman3.cels.anl.gov

Re: [mpiwg-p2p] Next meeting: 8th June 2015 11am Central US
by Balaji, Pavan 08 Jun '15

08 Jun '15

Hi Dan, Unfortunately, I'm on travel and won't be able to attend this call. Can someone else help discuss these tickets? For #479 and #480, they are both added for completeness. It's not necessary that they both be voted in. The WG could, for example, recommend that we drop one and only pursue the other. #479 is more of a "best effort" proposal for send cancel (basically the same state as we are in today with MPI implementations). #480 simply drops that ability, so there's no more send cancel. Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji From: Daniel Holmes Organization: EPCC Reply-To: "dholmes(a)epcc.ed.ac.uk<mailto:[email protected]>" Date: Monday, June 8, 2015 at 4:13 AM To: MPI Point To Point WG, Pavan Balaji Subject: Next meeting: 8th June 2015 11am Central US Hi all, The next point-to-point teleconference will be today on Monday 8th June 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage Agenda: 1) Ticket #476: "Can INFO keys change the semantic behaviour of MPI?" issue - the communicator assertions ticket was presented at the June Forum meeting and we got some useful feedback that we should discuss. 2) Tickets #478, #479, #480: "everything you ever wanted to know about MPI send cancel, plus a whole lot more" [new!] 3) New communicator INFO keys - it looks like these will be allowed, so we should define a few and get a proposal ready for the next face-to-face meeting 4) Progress on Arecv and Fsend or ReceiveReduce? 5) Other stuff? Cheers, Dan. -------- Forwarded Message -------- Subject: MPI Pt2pt WG tickets Date: Sun, 7 Jun 2015 21:04:50 +0000 From: Balaji, Pavan <balaji(a)anl.gov><mailto:[email protected]> To: Daniel Holmes <dholmes(a)epcc.ed.ac.uk><mailto:[email protected]> Hi Dan, I'd like to bring the following tickets forward to be vetted by the pt2pt WG before taking it to the Forum. Can you schedule some time for these in the WG telecon? When is the next telecon? 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 Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk<mailto:[email protected]> *Please consider the environment before printing this email.*

1 0

Re: [mpiwg-p2p] Next meeting: 8th June 2015 11am Central US
by Jeff Hammond 08 Jun '15

08 Jun '15

I'm very sorry to have to miss this call. At this point, please treat Recv_reduce as retired. We debated it within Intel and it was not viewed favorably enough to proceed. Arecv-Fsend is still active but there is nothing to report right now. It's possible that we will have something to share in Bordeaux, else I should have enough for a plenary in December. Jeff On Mon, Jun 8, 2015 at 2:13 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > Hi all, > > The next point-to-point teleconference will be today on Monday 8th June > 2015 at 11am Central US via webex. > > Connection details are on the point-to-point wiki page: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage > > Agenda: > 1) Ticket #476: "Can INFO keys change the semantic behaviour of MPI?" > issue - the communicator assertions ticket was presented at the June Forum > meeting and we got some useful feedback that we should discuss. > > 2) Tickets #478, #479, #480: "everything you ever wanted to know about MPI > send cancel, plus a whole lot more" [new!] > > 3) New communicator INFO keys - it looks like these will be allowed, so we > should define a few and get a proposal ready for the next face-to-face > meeting > > 4) Progress on Arecv and Fsend or ReceiveReduce? > > 5) Other stuff? > > Cheers, > Dan. > > -------- Forwarded Message -------- Subject: MPI Pt2pt WG tickets Date: Sun, > 7 Jun 2015 21:04:50 +0000 From: Balaji, Pavan <balaji(a)anl.gov> > <balaji(a)anl.gov> To: Daniel Holmes <dholmes(a)epcc.ed.ac.uk> > <dholmes(a)epcc.ed.ac.uk> > > Hi Dan, > > I'd like to bring the following tickets forward to be vetted by the > pt2pt WG before taking it to the Forum. Can you schedule some time for > these in the WG telecon? When is the next telecon? > > 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 > > Thanks, > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > > > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Next meeting: 8th June 2015 11am Central US
by Daniel Holmes 08 Jun '15

08 Jun '15

Hi all, The next point-to-point teleconference will be today on Monday 8th June 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage Agenda: 1) Ticket #476: "Can INFO keys change the semantic behaviour of MPI?" issue - the communicator assertions ticket was presented at the June Forum meeting and we got some useful feedback that we should discuss. 2) Tickets #478, #479, #480: "everything you ever wanted to know about MPI send cancel, plus a whole lot more" [new!] 3) New communicator INFO keys - it looks like these will be allowed, so we should define a few and get a proposal ready for the next face-to-face meeting 4) Progress on Arecv and Fsend or ReceiveReduce? 5) Other stuff? Cheers, Dan. -------- Forwarded Message -------- Subject: MPI Pt2pt WG tickets Date: Sun, 7 Jun 2015 21:04:50 +0000 From: Balaji, Pavan <balaji(a)anl.gov> To: Daniel Holmes <dholmes(a)epcc.ed.ac.uk> Hi Dan, I'd like to bring the following tickets forward to be vetted by the pt2pt WG before taking it to the Forum. Can you schedule some time for these in the WG telecon? When is the next telecon? 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 Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-p2p] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

Agreed. On 6/3/15, 8:18 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >Yes, I spoke loosely, but what I said doesn't change with that >distinction. "Matched" is a precursor to "received". > >"If the user never posts a receive, the send cancel should always >succeed." > >However, if you interpret "received at the destination" to include >unexpected queues, then one should not be able to cancel the request. > >My interpretation is the former one. But for either interpretation, the >standard must be clarified. > > -- Pavan > > >On 6/3/15, 8:13 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: > >>The standard distinguishes between “received” and “matched” very >>carefully. For example, MPI_Ssend() can return when the message is >>matched >>but not necessarily fully received. >> >>"A send that uses the synchronous mode can be started whether or not a >>matching >>receive was posted. However, the send will complete successfully only if >>a >>matching receive is >>posted, and the receive operation has started to receive the message sent >>by the synchronous >>send." >> >>Therefore, if the standard says “received”, I do not want to interpret >>that as “matched”. >> >>On 6/3/15, 8:03 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: >> >>> >>>If you interpret received at the destination as "matched", then what I >>>mentioned below holds -- if the user never posts a receive, the send >>>cancel should always succeed. >>> >>> -- Pavan >>> >>> >>> >>> >>>On 6/3/15, 7:59 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >>> >>>>+MPI P2P WG. >>>> >>>>We should probably discuss it in the P2P WG as well. >>>> >>>>I read the snippet of text and thought the “send” mentioned should >>>>correspond to the MPI send operation (the one the user issued), and not >>>>any internal buffering. “send completes normally” should mean the same >>>>thing as sends completing as if cancel wasn’t called. Similarly, >>>>“received >>>>at the destination” should mean the normal way messages are received at >>>>the destination i.e. by posting an MPI receive. Of course, these are my >>>>interpretations :) >>>> >>>>On 6/3/15, 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." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>

1 0

Re: [mpiwg-p2p] cancel in standard
by Balaji, Pavan 03 Jun '15

03 Jun '15

Yes, I spoke loosely, but what I said doesn't change with that distinction. "Matched" is a precursor to "received". "If the user never posts a receive, the send cancel should always succeed." However, if you interpret "received at the destination" to include unexpected queues, then one should not be able to cancel the request. My interpretation is the former one. But for either interpretation, the standard must be clarified. -- Pavan On 6/3/15, 8:13 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >The standard distinguishes between “received” and “matched” very >carefully. For example, MPI_Ssend() can return when the message is matched >but not necessarily fully received. > >"A send that uses the synchronous mode can be started whether or not a >matching >receive was posted. However, the send will complete successfully only if a >matching receive is >posted, and the receive operation has started to receive the message sent >by the synchronous >send." > >Therefore, if the standard says “received”, I do not want to interpret >that as “matched”. > >On 6/3/15, 8:03 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >> >>If you interpret received at the destination as "matched", then what I >>mentioned below holds -- if the user never posts a receive, the send >>cancel should always succeed. >> >> -- Pavan >> >> >> >> >>On 6/3/15, 7:59 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >> >>>+MPI P2P WG. >>> >>>We should probably discuss it in the P2P WG as well. >>> >>>I read the snippet of text and thought the “send” mentioned should >>>correspond to the MPI send operation (the one the user issued), and not >>>any internal buffering. “send completes normally” should mean the same >>>thing as sends completing as if cancel wasn’t called. Similarly, >>>“received >>>at the destination” should mean the normal way messages are received at >>>the destination i.e. by posting an MPI receive. Of course, these are my >>>interpretations :) >>> >>>On 6/3/15, 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." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >

1 0

Re: [mpiwg-p2p] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

The standard distinguishes between “received” and “matched” very carefully. For example, MPI_Ssend() can return when the message is matched but not necessarily fully received. "A send that uses the synchronous mode can be started whether or not a matching receive was posted. However, the send will complete successfully only if a matching receive is posted, and the receive operation has started to receive the message sent by the synchronous send." Therefore, if the standard says “received”, I do not want to interpret that as “matched”. On 6/3/15, 8:03 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >If you interpret received at the destination as "matched", then what I >mentioned below holds -- if the user never posts a receive, the send >cancel should always succeed. > > -- Pavan > > > > >On 6/3/15, 7:59 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: > >>+MPI P2P WG. >> >>We should probably discuss it in the P2P WG as well. >> >>I read the snippet of text and thought the “send” mentioned should >>correspond to the MPI send operation (the one the user issued), and not >>any internal buffering. “send completes normally” should mean the same >>thing as sends completing as if cancel wasn’t called. Similarly, >>“received >>at the destination” should mean the normal way messages are received at >>the destination i.e. by posting an MPI receive. Of course, these are my >>interpretations :) >> >>On 6/3/15, 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." >>>> >>>> >>>> >>>> >>>> >>>> >>

1 0

Re: [mpiwg-p2p] cancel in standard
by Balaji, Pavan 03 Jun '15

03 Jun '15

If you interpret received at the destination as "matched", then what I mentioned below holds -- if the user never posts a receive, the send cancel should always succeed. -- Pavan On 6/3/15, 7:59 PM, "Sur, Sayantan" <sayantan.sur(a)intel.com> wrote: >+MPI P2P WG. > >We should probably discuss it in the P2P WG as well. > >I read the snippet of text and thought the “send” mentioned should >correspond to the MPI send operation (the one the user issued), and not >any internal buffering. “send completes normally” should mean the same >thing as sends completing as if cancel wasn’t called. Similarly, “received >at the destination” should mean the normal way messages are received at >the destination i.e. by posting an MPI receive. Of course, these are my >interpretations :) > >On 6/3/15, 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." >>> >>> >>> >>> >>> >>> >

1 0

Re: [mpiwg-p2p] cancel in standard
by Sur, Sayantan 03 Jun '15

03 Jun '15

+MPI P2P WG. We should probably discuss it in the P2P WG as well. I read the snippet of text and thought the “send” mentioned should correspond to the MPI send operation (the one the user issued), and not any internal buffering. “send completes normally” should mean the same thing as sends completing as if cancel wasn’t called. Similarly, “received at the destination” should mean the normal way messages are received at the destination i.e. by posting an MPI receive. Of course, these are my interpretations :) On 6/3/15, 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." >> >> >> >> >> >>

1 0

Re: [mpiwg-p2p] Next meeting: 25th May 2015 11am Central US
by Jeff Hammond 25 May '15

25 May '15

It's a U.S. holiday today. Might not get many takers on this side of the pond. Jeff Sent from my iPhone > On May 25, 2015, at 2:33 AM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: > > Hi All, > > The next point-to-point teleconference will be today (in 4 and a bit hours' time), Monday 25th April 2015 at 11am Central US via webex. > > Connection details are on the point-to-point wiki page: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage > > Agenda: > 1) "Can INFO keys change the semantic behaviour of MPI?" issue - the communicator assertions ticket is ready for Forum feedback, time has been requested for an informal reading in June. > 2) New communicator INFO keys - it looks like these will be allowed, so we should define a few and get a proposal ready for the next face-to-face meeting > 3) Progress on Arecv and Fsend or ReceiveReduce? > 4) Other stuff? > > Cheers, > Dan. > >> On 27/04/2015 15:29, Daniel Holmes wrote: >> Hi All, >> >> I am cancelling the point-to-point teleconference today because I have not had time to progress the work on communicator assertions since last time and I am not aware of any other ongoing work for us to talk about. >> >> Looking forward to figure out when the next meeting will take place, I won't be available for the next two teleconferences due to travelling. This means that the next meeting date would be 25th May, i.e. one week before the face-to-face meeting in Chicago. >> >> I will send out a reminder nearer the time and will communicate any progress in the interim via email. >> >> Cheers, >> Dan. >> >>> On 13/04/2015 10:32, Daniel Holmes wrote: >>> Hi All, >>> >>> The next point-to-point teleconference will be today, Monday 13th April 2015 at 11am Central US via webex. >>> >>> Connection details are on the point-to-point wiki page: >>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage >>> >>> Agenda: >>> 0) Discuss/agree the to-do list (see below) that covers the next two agenda items. >>> 1) "Can INFO keys change the semantic behaviour of MPI?" issue - following the discussion at the face-to-face meeting, we seem to have a workable way forward on this issue! >>> 2) New communicator INFO keys - it looks like these will be allowed, so we should define a few and get a proposal ready for the next face-to-face meeting >>> 3) Progress on Arecv and Fsend or ReceiveReduce? >>> 4) Other stuff? >>> >>> Cheers, >>> Dan. >>> >>>> Hi All, >>>> >>>> At the last telco meeting, Jim asked for a to-do list of the tasks needed to move communicator assertions forward. Please find below a first draft of such a task list. Could we agree that this is a good list? If you see something odd/missing, reply to this email group. >>>> >>>> To-do list for communicator assertions >>>> >>>> 0) Gather evidence to support "no-one will be affected by backwards incompatibility". >>>> (e.g. chase Pavan, who volunteered to do this for major MPICH users) >>>> 1) Change behaviour of MPI_COMM_DUP so that INFO keys are *not* propagated to new comm. >>>> (include AtoU: if you want to dup INFO use MPI_COMM_DUP_WITH_INFO, with example) >>>> 2) Discuss whether attributes (plus, anything else?) should be propagated by MPI_COMM_DUP. >>>> (default presumption is yes, they should still be propagated). >>>> 3) Find all occurrence of language in the MPI Standard that suggests INFO keys are hints. >>>> a) Change or remove any generic statements like "INFO keys cannot change semantics". >>>> (e.g. change to "cannot change observable semantics" or remove) >>>> b) For each occurrence, determine if it should continue to suggest hint status >>>> (e.g. a particular key, most likely for the I/O keys but maybe also some RMA keys) >>>> >>>> A) Convert ticket 381 into "make comm assertions doable" proposal (by Jun 2015 - Chicago?) >>>> B) Get "no wildcard" INFO keys proposal ready for formal reading (by Jun 2015 - Chicago?) >>>> C) Get "no ordering" INFO key proposal ready for formal reading (by Jun 2015 - Chicago?) >>>> D) Get "no cancel" INFO keys proposal ready for formal reading (by Jun 2015 - Chicago?) >>>> E) Discuss other INFO key proposals, e.g. "only wildcard", "no non-blocking", "no underflow" >>>> >>>> Cheers, >>>> Dan. >>> >>> -- >>> Dan Holmes >>> Applications Consultant in HPC Research >>> EPCC, The University of Edinburgh >>> James Clerk Maxwell Building >>> The Kings Buildings >>> Peter Guthrie Tait Road >>> Edinburgh >>> EH9 3FD >>> T: +44(0)131 651 3465 >>> E: dholmes(a)epcc.ed.ac.uk >>> >>> *Please consider the environment before printing this email.* >> >> -- >> Dan Holmes >> Applications Consultant in HPC Research >> EPCC, The University of Edinburgh >> James Clerk Maxwell Building >> The Kings Buildings >> Peter Guthrie Tait Road >> Edinburgh >> EH9 3FD >> T: +44(0)131 651 3465 >> E: dholmes(a)epcc.ed.ac.uk >> >> *Please consider the environment before printing this email.* >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E: dholmes(a)epcc.ed.ac.uk > > *Please consider the environment before printing this email.* > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p

1 0

Re: [mpiwg-p2p] Next meeting: 25th May 2015 11am Central US
by Daniel Holmes 25 May '15

25 May '15

Hi All, The next point-to-point teleconference will be today (in 4 and a bit hours' time), Monday 25th April 2015 at 11am Central US via webex. Connection details are on the point-to-point wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage Agenda: 1) "Can INFO keys change the semantic behaviour of MPI?" issue - the communicator assertions ticket is ready for Forum feedback, time has been requested for an informal reading in June. 2) New communicator INFO keys - it looks like these will be allowed, so we should define a few and get a proposal ready for the next face-to-face meeting 3) Progress on Arecv and Fsend or ReceiveReduce? 4) Other stuff? Cheers, Dan. On 27/04/2015 15:29, Daniel Holmes wrote: > Hi All, > > I am cancelling the point-to-point teleconference today because I have > not had time to progress the work on communicator assertions since > last time and I am not aware of any other ongoing work for us to talk > about. > > Looking forward to figure out when the next meeting will take place, I > won't be available for the next two teleconferences due to travelling. > This means that the next meeting date would be 25th May, i.e. one week > before the face-to-face meeting in Chicago. > > I will send out a reminder nearer the time and will communicate any > progress in the interim via email. > > Cheers, > Dan. > > On 13/04/2015 10:32, Daniel Holmes wrote: >> Hi All, >> >> The next point-to-point teleconference will be today, Monday 13th >> April 2015 at 11am Central US via webex. >> >> Connection details are on the point-to-point wiki page: >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage >> >> Agenda: >> 0) Discuss/agree the to-do list (see below) that covers the next two >> agenda items. >> 1) "Can INFO keys change the semantic behaviour of MPI?" issue - >> following the discussion at the face-to-face meeting, we seem to have >> a workable way forward on this issue! >> 2) New communicator INFO keys - it looks like these will be allowed, >> so we should define a few and get a proposal ready for the next >> face-to-face meeting >> 3) Progress on Arecv and Fsend or ReceiveReduce? >> 4) Other stuff? >> >> Cheers, >> Dan. >> >>> Hi All, >>> >>> At the last telco meeting, Jim asked for a to-do list of the tasks >>> needed to move communicator assertions forward. Please find below a >>> first draft of such a task list. Could we agree that this is a good >>> list? If you see something odd/missing, reply to this email group. >>> >>> _To-do list for communicator assertions__ >>> _ >>> 0) Gather evidence to support "no-one will be affected by backwards >>> incompatibility". >>> (e.g. chase Pavan, who volunteered to do this for major MPICH users) >>> 1) Change behaviour of MPI_COMM_DUP so that INFO keys are *not* >>> propagated to new comm. >>> (include AtoU: if you want to dup INFO use >>> MPI_COMM_DUP_WITH_INFO, with example) >>> 2) Discuss whether attributes (plus, anything else?) should be >>> propagated by MPI_COMM_DUP. >>> (default presumption is yes, they should still be propagated). >>> 3) Find all occurrence of language in the MPI Standard that suggests >>> INFO keys are hints. >>> a) Change or remove any generic statements like "INFO keys cannot >>> change semantics". >>> (e.g. change to "cannot change observable semantics" or remove) >>> b) For each occurrence, determine if it should continue to suggest >>> hint status >>> (e.g. a particular key, most likely for the I/O keys but maybe >>> also some RMA keys) >>> >>> A) Convert ticket 381 into "make comm assertions doable" proposal >>> (by Jun 2015 - Chicago?) >>> B) Get "no wildcard" INFO keys proposal ready for formal reading (by >>> Jun 2015 - Chicago?) >>> C) Get "no ordering" INFO key proposal ready for formal reading (by >>> Jun 2015 - Chicago?) >>> D) Get "no cancel" INFO keys proposal ready for formal reading (by >>> Jun 2015 - Chicago?) >>> E) Discuss other INFO key proposals, e.g. "only wildcard", "no >>> non-blocking", "no underflow" >>> >>> Cheers, >>> Dan. >> >> -- >> Dan Holmes >> Applications Consultant in HPC Research >> EPCC, The University of Edinburgh >> James Clerk Maxwell Building >> The Kings Buildings >> Peter Guthrie Tait Road >> Edinburgh >> EH9 3FD >> T: +44(0)131 651 3465 >> E:[email protected] >> >> *Please consider the environment before printing this email.* > > -- > Dan Holmes > Applications Consultant in HPC Research > EPCC, The University of Edinburgh > James Clerk Maxwell Building > The Kings Buildings > Peter Guthrie Tait Road > Edinburgh > EH9 3FD > T: +44(0)131 651 3465 > E:[email protected] > > *Please consider the environment before printing this email.* > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Peter Guthrie Tait Road Edinburgh EH9 3FD T: +44(0)131 651 3465 E: dholmes(a)epcc.ed.ac.uk *Please consider the environment before printing this email.* The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0