August 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert
by William Gropp 09 Aug '12

09 Aug '12

Agreed. This has always been a "quality of implementation" issue, since, as Jeff notes, providing fairness, particularly a specifically defined fairness, can have significant performance implications. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Aug 9, 2012, at 6:01 AM, Jeff Hammond wrote: > I think this is very thorough and useful. I also agree that fairness > should absolutely not be added to the standard. It's a nightmare for > performance in some cases. > > Jeff > > On Thu, Aug 9, 2012 at 4:55 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> Rich, >> >> yes and no: >> - Yes, any real change about fairness is going beyond MPI-3.0. >> >> - No, the current text is not clear enough because there is no >> reference between MPI_ANY_SOURCE and the "lack of fairness" statement. >> For this, I proposed the clarifications below. >> >> What does the Pt-to-Pt chapter team, i.e., >> Richard Graham(c), Anthony Skjellum, Fab Tillier, Brian Smith, >> Devendar Bureddy, Bill Gropp, Torsten Hoefler, Adam Moody, >> Martin Schulz, Brian Barrett, >> think about my proposal? >> >> - And all discussion on any changes of the current text should go >> through "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> otherwise the risk of problems popping up between Sep 12 and Sep 20 >> is to big. >> >> Best regards >> Rolf >> >> ----- Original Message ----- >>> From: "Richard Graham" <richardg(a)mellanox.com> >>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>> Sent: Thursday, August 9, 2012 11:23:57 AM >>> Subject: Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert >>> Rolf, >>> Thanks a lot for the help here, but this is really not needed at this >>> stage. I have started to farm off requests to the appropriate working >>> groups. In this case, the response will be that we will need a >>> specific proposal for something to happen beyond MPI 3.0, as this can >>> be either an implementation issue, or a change in long-standing >>> semantics, which are beyond the scope of the current work. >>> >>> Thanks, >>> Rich >>> >>> -----Original Message----- >>> From: mpi-forum-bounces(a)lists.mpi-forum.org >>> [mailto:[email protected]] On Behalf Of Rolf >>> Rabenseifner >>> Sent: Thursday, August 09, 2012 12:20 PM >>> To: Main MPI Forum mailing list >>> Subject: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 >>> comment by Sebastien Boisvert >>> >>> I try to test the proposed process for comments. >>> >>> This comment is about the Point-to-Point chapter. >>> Rich is the chapter author. >>> >>> Here is the comment (see bottom of this email) together with my reply >>> to the comment's author and a first proposal for solving it: >>> >>> All references are related to >>> http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >>> >>> Summary about the comment: >>> ========================== >>> >>> The text in new MPI_IMPROBE about MPI_ANY_SOURCE does not say anything >>> about fairness. >>> The commentator asks for a round-robin fairness behavior. >>> >>> Summary of my proposal to answer this comment: >>> ============================================== >>> >>> - Keep the unfair behavior as defined on p42:10-17 >>> - Clarify this faiirness-paragraph to make clear >>> that it also applies to MPI_ANY_SOURCE. >>> - Add cross-references between p42:10-17, MPI_RECV >>> and all MPI_PROBE routines to make clear that >>> there is no fairness with MPI_ANY_SOURCE. >>> >>> Proposed solution: >>> ================== >>> >>> All references are related to >>> http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >>> >>> mpi3.0_draft_2.pdf p29:25-31 read >>> >>> The receiver may specify a wildcard MPI_ANY_SOURCE value >>> for source, and/or a wildcard MPI_ANY_TAG value for tag, >>> indicating that any source and/or tag are acceptable. >>> It cannot specify a wildcard value for comm. Thus, a message >>> can be received by a receive operation only if it is addressed >>> to the receiving process, has a matching communicator, has >>> matching source unless source=MPI_ANY_SOURCE in the pattern, >>> and has a matching tag unless tag=MPI_ANY_TAG in the pattern. >>> >>> and the following text should be added: >>> >>> Note that MPI makes no guarantee of fairness in >>> the handling of communication, especially when using >>> MPI_ANY_SOURCE; for details see the section on {\em Fairness} >>> on page 42. >>> >>> >>> mpi3.0_draft_2.pdf p42:10 read >>> >>> Fairness[ ] MPI makes no guarantee of fairness in the handling >>> of communication. >>> >>> but should read >>> >>> Fairness[ ] MPI makes no guarantee of fairness in the handling >>> of communication, e.g., when using MPI_ANY_SOURCE, MPI_WAITANY >>> or MPI_WAITSOME in a singlethreaded process, or using MPI_RECV >>> or MPI_MPROBE by several threads in a multithreaded process. >>> >>> >>> mpi3.0_draft_2.pdf p65:16-18 (in the definition of MPI_IPROBE) read >>> >>> The call matches the same message that would have been received >>> by a call to MPI_RECV(..., source, tag, comm, status) executed >>> at the same point in the program, and returns in status the >>> same value that would have been returned by MPI_RECV(). >>> >>> but should read (only the reference on the last line is added): >>> >>> The call matches the same message that would have been received >>> by a call to MPI_RECV(..., source, tag, comm, status) executed >>> at the same point in the program, and returns in status the >>> same value that would have been returned by MPI_RECV(), >>> see Section 3.2.4 on page 28. >>> >>> >>> mpi3.0_draft_2.pdf p68:33-35 (in the definition of MPI_IMPROBE) read >>> >>> The call matches the same message that would have been received >>> by a call to MPI_RECV(..., source, tag, comm, status) executed >>> at the same point in the program and returns in status the >>> same value that would have been returned by MPI_RECV. >>> >>> but should read (only the reference on the last line is added): >>> >>> The call matches the same message that would have been received >>> by a call to MPI_RECV(..., source, tag, comm, status) executed >>> at the same point in the program and returns in status the >>> same value that would have been returned by MPI_RECV, >>> see Section 3.2.4 on page 28. >>> >>> >>> Proposed answer to the commentator >>> (together with the proposed solution): >>> ====================================== >>> >>> MPI defines to be unfair, see page 42, lines 10-17. >>> Cross-references were missing in the MPI standard, i.e., it was not >>> easy to detect that this paragraph on fairness also applies to >>> MPI_ANY_SOURCE in any call (MPI_RECV, MPI_IRECV, and all versions of >>> MPI_PROBE) The proposed solution adds the missing cross-references. >>> >>> For performance reasons, the MPI Forum decided not to change this >>> "unfair" behavior. >>> >>> You may use other mechanisms to implement some sort of fairness. >>> Especially the tag can be used in a cyclic way (i.e. with values >>> between 0 and 32767) to implement some sort of fairness, but this is >>> outside of the scope of the MPI standard. >>> >>> We did not add an advice to users about mechanisms to implement some >>> sort of fairness within the application. >>> Such an advice would go beyond the task of the MPI standard. >>> >>> >>> Background (not to be part of the answer to the commentator) >>> ============================================================ >>> >>> The following part of the comment >>>> Presently, the MPI standard contains nothing about which source >>>> should >>>> be probed when MPI_ANY_SOURCE is provided. >>> is not fully true. >>> The MPI standard clearly states in mpi3.0_draft_2.pdf in >>> Section 3.5 Semantics of Point-to-Point Communication >>> on page 42 lines 10-17 >>> >>> Fairness. MPI makes no guarantee of fairness in >>> the handling of communication. Suppose that a send is >>> posted. Then it is possible that the destination process >>> repeatedly posts a receive that matches this send, yet >>> the message is never received, because it is each time >>> overtaken by another message, sent from another source. >>> Similarly, suppose that a receive was posted by a >>> multithreaded process. Then it is possible that messages >>> that match this receive are repeatedly received, yet the >>> receive is never satisfied, because it is overtaken >>> by other receives posted at this node (by other >>> executing threads). It is the programmer's >>> responsibility to prevent starvation in such situations. >>> >>> that there is no fairness. >>> And I expect that the MPI Forum does not want to change >>> this statement. >>> This section does not mention MPI_ANY_SOURCE. >>> My proposal adds here a note on MPI_ANY_SOURCE that >>> readers can find the Fairness paragraph when the look at all >>> locations of MPI_ANY_SOURCE. >>> >>> MPI_ANY_SOURCE is defined in the text about the source rank >>> of MPI_RECV without any reference to the Fairness paragraph, >>> see page 29 lines 23-31. >>> I added a reference to the Fairness paragraph to solve this >>> lack of reference. >>> >>> And MPI_IPROBE and MPI_IMPROBE have own text on MPI_ANY_SOURCE. >>> Here I would propose to add only a reference to Section 3.2.4, >>> which defines MPI_RECV and which should contain the >>> reference to the fairness paragraph. >>> >>> ---------------------- >>> My goal was not to change anything, i.e., only to add >>> clarifying references. >>> Any comments about this proposal? >>> Corrections about my wording? >>> Agreed? >>> >>> Best regards >>> Rolf >>> >>> >>> ----- Forwarded Message ----- >>> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> To: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> >>> Sent: Thursday, August 9, 2012 8:09:49 AM >>> Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August >>> 2012 >>> >>> Dear Mr. Boisvert, >>> >>> the MPI Forum will discuss your comment >>> and will return an answer before our meeting >>> Sep. 20-21 in Vienna. >>> >>> Best regards >>> Rolf Rabenseifner >>> >>> ----- Original Message ----- >>>> From: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> >>>> To: mpi-comments(a)mpi-forum.org >>>> Sent: Sunday, August 5, 2012 6:50:29 AM >>>> Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 >>>> Dear MPI Forum committee members, >>>> >>>> I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 >>>> for your consideration. >>>> >>>> Version: MPI-3.0 Draft 2, August 2012. >>>> >>>> The URL of the version of the MPI standard: >>>> http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >>>> >>>> Page: 65 >>>> >>>> Line number: 28 >>>> >>>> Section: 3.8.1 >>>> >>>> In: >>>> >>>> 3. Point-to-Point Communication >>>> 3.8 Probe and Cancel >>>> 3.8.1 Probe >>>> >>>> Comment: >>>> >>>> It says that the source argument of MPI_Iprobe can be >>>> MPI_ANY_SOURCE, >>>> but it >>>> does say anything about fairness. Therefore MPI_ANY_SOURCE can lead >>>> to >>>> resource >>>> starvation. >>>> >>>> I think it would be better if probing would be done in a round-robin >>>> fashion >>>> when the source is MPI_ANY_SOURCE so that any MPI rank has an equal >>>> chance of >>>> having its message probed and received. >>>> >>>> Presently, the MPI standard contains nothing about which source >>>> should >>>> be probed when >>>> MPI_ANY_SOURCE is provided. >>>> >>>> I hope you will consider my comment. >>>> >>>> >>>> Sincerely, >>>> >>>> >>>> Sï¿½bastien Boisvert >>>> PhD student >>>> Universitï¿½ Laval >>>> >>>> _______________________________________________ >>>> mpi-comments mailing list >>>> mpi-comments(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments >> >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > _______________________________________________ > 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] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert
by Jeff Hammond 09 Aug '12

09 Aug '12

I think this is very thorough and useful. I also agree that fairness should absolutely not be added to the standard. It's a nightmare for performance in some cases. Jeff On Thu, Aug 9, 2012 at 4:55 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Rich, > > yes and no: > - Yes, any real change about fairness is going beyond MPI-3.0. > > - No, the current text is not clear enough because there is no > reference between MPI_ANY_SOURCE and the "lack of fairness" statement. > For this, I proposed the clarifications below. > > What does the Pt-to-Pt chapter team, i.e., > Richard Graham(c), Anthony Skjellum, Fab Tillier, Brian Smith, > Devendar Bureddy, Bill Gropp, Torsten Hoefler, Adam Moody, > Martin Schulz, Brian Barrett, > think about my proposal? > > - And all discussion on any changes of the current text should go > through "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > otherwise the risk of problems popping up between Sep 12 and Sep 20 > is to big. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Richard Graham" <richardg(a)mellanox.com> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Thursday, August 9, 2012 11:23:57 AM >> Subject: Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert >> Rolf, >> Thanks a lot for the help here, but this is really not needed at this >> stage. I have started to farm off requests to the appropriate working >> groups. In this case, the response will be that we will need a >> specific proposal for something to happen beyond MPI 3.0, as this can >> be either an implementation issue, or a change in long-standing >> semantics, which are beyond the scope of the current work. >> >> Thanks, >> Rich >> >> -----Original Message----- >> From: mpi-forum-bounces(a)lists.mpi-forum.org >> [mailto:[email protected]] On Behalf Of Rolf >> Rabenseifner >> Sent: Thursday, August 09, 2012 12:20 PM >> To: Main MPI Forum mailing list >> Subject: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 >> comment by Sebastien Boisvert >> >> I try to test the proposed process for comments. >> >> This comment is about the Point-to-Point chapter. >> Rich is the chapter author. >> >> Here is the comment (see bottom of this email) together with my reply >> to the comment's author and a first proposal for solving it: >> >> All references are related to >> http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >> >> Summary about the comment: >> ========================== >> >> The text in new MPI_IMPROBE about MPI_ANY_SOURCE does not say anything >> about fairness. >> The commentator asks for a round-robin fairness behavior. >> >> Summary of my proposal to answer this comment: >> ============================================== >> >> - Keep the unfair behavior as defined on p42:10-17 >> - Clarify this faiirness-paragraph to make clear >> that it also applies to MPI_ANY_SOURCE. >> - Add cross-references between p42:10-17, MPI_RECV >> and all MPI_PROBE routines to make clear that >> there is no fairness with MPI_ANY_SOURCE. >> >> Proposed solution: >> ================== >> >> All references are related to >> http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >> >> mpi3.0_draft_2.pdf p29:25-31 read >> >> The receiver may specify a wildcard MPI_ANY_SOURCE value >> for source, and/or a wildcard MPI_ANY_TAG value for tag, >> indicating that any source and/or tag are acceptable. >> It cannot specify a wildcard value for comm. Thus, a message >> can be received by a receive operation only if it is addressed >> to the receiving process, has a matching communicator, has >> matching source unless source=MPI_ANY_SOURCE in the pattern, >> and has a matching tag unless tag=MPI_ANY_TAG in the pattern. >> >> and the following text should be added: >> >> Note that MPI makes no guarantee of fairness in >> the handling of communication, especially when using >> MPI_ANY_SOURCE; for details see the section on {\em Fairness} >> on page 42. >> >> >> mpi3.0_draft_2.pdf p42:10 read >> >> Fairness[ ] MPI makes no guarantee of fairness in the handling >> of communication. >> >> but should read >> >> Fairness[ ] MPI makes no guarantee of fairness in the handling >> of communication, e.g., when using MPI_ANY_SOURCE, MPI_WAITANY >> or MPI_WAITSOME in a singlethreaded process, or using MPI_RECV >> or MPI_MPROBE by several threads in a multithreaded process. >> >> >> mpi3.0_draft_2.pdf p65:16-18 (in the definition of MPI_IPROBE) read >> >> The call matches the same message that would have been received >> by a call to MPI_RECV(..., source, tag, comm, status) executed >> at the same point in the program, and returns in status the >> same value that would have been returned by MPI_RECV(). >> >> but should read (only the reference on the last line is added): >> >> The call matches the same message that would have been received >> by a call to MPI_RECV(..., source, tag, comm, status) executed >> at the same point in the program, and returns in status the >> same value that would have been returned by MPI_RECV(), >> see Section 3.2.4 on page 28. >> >> >> mpi3.0_draft_2.pdf p68:33-35 (in the definition of MPI_IMPROBE) read >> >> The call matches the same message that would have been received >> by a call to MPI_RECV(..., source, tag, comm, status) executed >> at the same point in the program and returns in status the >> same value that would have been returned by MPI_RECV. >> >> but should read (only the reference on the last line is added): >> >> The call matches the same message that would have been received >> by a call to MPI_RECV(..., source, tag, comm, status) executed >> at the same point in the program and returns in status the >> same value that would have been returned by MPI_RECV, >> see Section 3.2.4 on page 28. >> >> >> Proposed answer to the commentator >> (together with the proposed solution): >> ====================================== >> >> MPI defines to be unfair, see page 42, lines 10-17. >> Cross-references were missing in the MPI standard, i.e., it was not >> easy to detect that this paragraph on fairness also applies to >> MPI_ANY_SOURCE in any call (MPI_RECV, MPI_IRECV, and all versions of >> MPI_PROBE) The proposed solution adds the missing cross-references. >> >> For performance reasons, the MPI Forum decided not to change this >> "unfair" behavior. >> >> You may use other mechanisms to implement some sort of fairness. >> Especially the tag can be used in a cyclic way (i.e. with values >> between 0 and 32767) to implement some sort of fairness, but this is >> outside of the scope of the MPI standard. >> >> We did not add an advice to users about mechanisms to implement some >> sort of fairness within the application. >> Such an advice would go beyond the task of the MPI standard. >> >> >> Background (not to be part of the answer to the commentator) >> ============================================================ >> >> The following part of the comment >> > Presently, the MPI standard contains nothing about which source >> > should >> > be probed when MPI_ANY_SOURCE is provided. >> is not fully true. >> The MPI standard clearly states in mpi3.0_draft_2.pdf in >> Section 3.5 Semantics of Point-to-Point Communication >> on page 42 lines 10-17 >> >> Fairness. MPI makes no guarantee of fairness in >> the handling of communication. Suppose that a send is >> posted. Then it is possible that the destination process >> repeatedly posts a receive that matches this send, yet >> the message is never received, because it is each time >> overtaken by another message, sent from another source. >> Similarly, suppose that a receive was posted by a >> multithreaded process. Then it is possible that messages >> that match this receive are repeatedly received, yet the >> receive is never satisfied, because it is overtaken >> by other receives posted at this node (by other >> executing threads). It is the programmer's >> responsibility to prevent starvation in such situations. >> >> that there is no fairness. >> And I expect that the MPI Forum does not want to change >> this statement. >> This section does not mention MPI_ANY_SOURCE. >> My proposal adds here a note on MPI_ANY_SOURCE that >> readers can find the Fairness paragraph when the look at all >> locations of MPI_ANY_SOURCE. >> >> MPI_ANY_SOURCE is defined in the text about the source rank >> of MPI_RECV without any reference to the Fairness paragraph, >> see page 29 lines 23-31. >> I added a reference to the Fairness paragraph to solve this >> lack of reference. >> >> And MPI_IPROBE and MPI_IMPROBE have own text on MPI_ANY_SOURCE. >> Here I would propose to add only a reference to Section 3.2.4, >> which defines MPI_RECV and which should contain the >> reference to the fairness paragraph. >> >> ---------------------- >> My goal was not to change anything, i.e., only to add >> clarifying references. >> Any comments about this proposal? >> Corrections about my wording? >> Agreed? >> >> Best regards >> Rolf >> >> >> ----- Forwarded Message ----- >> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> To: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> >> Sent: Thursday, August 9, 2012 8:09:49 AM >> Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August >> 2012 >> >> Dear Mr. Boisvert, >> >> the MPI Forum will discuss your comment >> and will return an answer before our meeting >> Sep. 20-21 in Vienna. >> >> Best regards >> Rolf Rabenseifner >> >> ----- Original Message ----- >> > From: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> >> > To: mpi-comments(a)mpi-forum.org >> > Sent: Sunday, August 5, 2012 6:50:29 AM >> > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 >> > Dear MPI Forum committee members, >> > >> > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 >> > for your consideration. >> > >> > Version: MPI-3.0 Draft 2, August 2012. >> > >> > The URL of the version of the MPI standard: >> > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf >> > >> > Page: 65 >> > >> > Line number: 28 >> > >> > Section: 3.8.1 >> > >> > In: >> > >> > 3. Point-to-Point Communication >> > 3.8 Probe and Cancel >> > 3.8.1 Probe >> > >> > Comment: >> > >> > It says that the source argument of MPI_Iprobe can be >> > MPI_ANY_SOURCE, >> > but it >> > does say anything about fairness. Therefore MPI_ANY_SOURCE can lead >> > to >> > resource >> > starvation. >> > >> > I think it would be better if probing would be done in a round-robin >> > fashion >> > when the source is MPI_ANY_SOURCE so that any MPI rank has an equal >> > chance of >> > having its message probed and received. >> > >> > Presently, the MPI standard contains nothing about which source >> > should >> > be probed when >> > MPI_ANY_SOURCE is provided. >> > >> > I hope you will consider my comment. >> > >> > >> > Sincerely, >> > >> > >> > Sï¿½bastien Boisvert >> > PhD student >> > Universitï¿½ Laval >> > >> > _______________________________________________ >> > mpi-comments mailing list >> > mpi-comments(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert
by Rolf Rabenseifner 09 Aug '12

09 Aug '12

Rich, yes and no: - Yes, any real change about fairness is going beyond MPI-3.0. - No, the current text is not clear enough because there is no reference between MPI_ANY_SOURCE and the "lack of fairness" statement. For this, I proposed the clarifications below. What does the Pt-to-Pt chapter team, i.e., Richard Graham(c), Anthony Skjellum, Fab Tillier, Brian Smith, Devendar Bureddy, Bill Gropp, Torsten Hoefler, Adam Moody, Martin Schulz, Brian Barrett, think about my proposal? - And all discussion on any changes of the current text should go through "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> otherwise the risk of problems popping up between Sep 12 and Sep 20 is to big. Best regards Rolf ----- Original Message ----- > From: "Richard Graham" <richardg(a)mellanox.com> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Thursday, August 9, 2012 11:23:57 AM > Subject: Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert > Rolf, > Thanks a lot for the help here, but this is really not needed at this > stage. I have started to farm off requests to the appropriate working > groups. In this case, the response will be that we will need a > specific proposal for something to happen beyond MPI 3.0, as this can > be either an implementation issue, or a change in long-standing > semantics, which are beyond the scope of the current work. > > Thanks, > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Rolf > Rabenseifner > Sent: Thursday, August 09, 2012 12:20 PM > To: Main MPI Forum mailing list > Subject: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 > comment by Sebastien Boisvert > > I try to test the proposed process for comments. > > This comment is about the Point-to-Point chapter. > Rich is the chapter author. > > Here is the comment (see bottom of this email) together with my reply > to the comment's author and a first proposal for solving it: > > All references are related to > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > Summary about the comment: > ========================== > > The text in new MPI_IMPROBE about MPI_ANY_SOURCE does not say anything > about fairness. > The commentator asks for a round-robin fairness behavior. > > Summary of my proposal to answer this comment: > ============================================== > > - Keep the unfair behavior as defined on p42:10-17 > - Clarify this faiirness-paragraph to make clear > that it also applies to MPI_ANY_SOURCE. > - Add cross-references between p42:10-17, MPI_RECV > and all MPI_PROBE routines to make clear that > there is no fairness with MPI_ANY_SOURCE. > > Proposed solution: > ================== > > All references are related to > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > mpi3.0_draft_2.pdf p29:25-31 read > > The receiver may specify a wildcard MPI_ANY_SOURCE value > for source, and/or a wildcard MPI_ANY_TAG value for tag, > indicating that any source and/or tag are acceptable. > It cannot specify a wildcard value for comm. Thus, a message > can be received by a receive operation only if it is addressed > to the receiving process, has a matching communicator, has > matching source unless source=MPI_ANY_SOURCE in the pattern, > and has a matching tag unless tag=MPI_ANY_TAG in the pattern. > > and the following text should be added: > > Note that MPI makes no guarantee of fairness in > the handling of communication, especially when using > MPI_ANY_SOURCE; for details see the section on {\em Fairness} > on page 42. > > > mpi3.0_draft_2.pdf p42:10 read > > Fairness[ ] MPI makes no guarantee of fairness in the handling > of communication. > > but should read > > Fairness[ ] MPI makes no guarantee of fairness in the handling > of communication, e.g., when using MPI_ANY_SOURCE, MPI_WAITANY > or MPI_WAITSOME in a singlethreaded process, or using MPI_RECV > or MPI_MPROBE by several threads in a multithreaded process. > > > mpi3.0_draft_2.pdf p65:16-18 (in the definition of MPI_IPROBE) read > > The call matches the same message that would have been received > by a call to MPI_RECV(..., source, tag, comm, status) executed > at the same point in the program, and returns in status the > same value that would have been returned by MPI_RECV(). > > but should read (only the reference on the last line is added): > > The call matches the same message that would have been received > by a call to MPI_RECV(..., source, tag, comm, status) executed > at the same point in the program, and returns in status the > same value that would have been returned by MPI_RECV(), > see Section 3.2.4 on page 28. > > > mpi3.0_draft_2.pdf p68:33-35 (in the definition of MPI_IMPROBE) read > > The call matches the same message that would have been received > by a call to MPI_RECV(..., source, tag, comm, status) executed > at the same point in the program and returns in status the > same value that would have been returned by MPI_RECV. > > but should read (only the reference on the last line is added): > > The call matches the same message that would have been received > by a call to MPI_RECV(..., source, tag, comm, status) executed > at the same point in the program and returns in status the > same value that would have been returned by MPI_RECV, > see Section 3.2.4 on page 28. > > > Proposed answer to the commentator > (together with the proposed solution): > ====================================== > > MPI defines to be unfair, see page 42, lines 10-17. > Cross-references were missing in the MPI standard, i.e., it was not > easy to detect that this paragraph on fairness also applies to > MPI_ANY_SOURCE in any call (MPI_RECV, MPI_IRECV, and all versions of > MPI_PROBE) The proposed solution adds the missing cross-references. > > For performance reasons, the MPI Forum decided not to change this > "unfair" behavior. > > You may use other mechanisms to implement some sort of fairness. > Especially the tag can be used in a cyclic way (i.e. with values > between 0 and 32767) to implement some sort of fairness, but this is > outside of the scope of the MPI standard. > > We did not add an advice to users about mechanisms to implement some > sort of fairness within the application. > Such an advice would go beyond the task of the MPI standard. > > > Background (not to be part of the answer to the commentator) > ============================================================ > > The following part of the comment > > Presently, the MPI standard contains nothing about which source > > should > > be probed when MPI_ANY_SOURCE is provided. > is not fully true. > The MPI standard clearly states in mpi3.0_draft_2.pdf in > Section 3.5 Semantics of Point-to-Point Communication > on page 42 lines 10-17 > > Fairness. MPI makes no guarantee of fairness in > the handling of communication. Suppose that a send is > posted. Then it is possible that the destination process > repeatedly posts a receive that matches this send, yet > the message is never received, because it is each time > overtaken by another message, sent from another source. > Similarly, suppose that a receive was posted by a > multithreaded process. Then it is possible that messages > that match this receive are repeatedly received, yet the > receive is never satisfied, because it is overtaken > by other receives posted at this node (by other > executing threads). It is the programmer's > responsibility to prevent starvation in such situations. > > that there is no fairness. > And I expect that the MPI Forum does not want to change > this statement. > This section does not mention MPI_ANY_SOURCE. > My proposal adds here a note on MPI_ANY_SOURCE that > readers can find the Fairness paragraph when the look at all > locations of MPI_ANY_SOURCE. > > MPI_ANY_SOURCE is defined in the text about the source rank > of MPI_RECV without any reference to the Fairness paragraph, > see page 29 lines 23-31. > I added a reference to the Fairness paragraph to solve this > lack of reference. > > And MPI_IPROBE and MPI_IMPROBE have own text on MPI_ANY_SOURCE. > Here I would propose to add only a reference to Section 3.2.4, > which defines MPI_RECV and which should contain the > reference to the fairness paragraph. > > ---------------------- > My goal was not to change anything, i.e., only to add > clarifying references. > Any comments about this proposal? > Corrections about my wording? > Agreed? > > Best regards > Rolf > > > ----- Forwarded Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > Sent: Thursday, August 9, 2012 8:09:49 AM > Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August > 2012 > > Dear Mr. Boisvert, > > the MPI Forum will discuss your comment > and will return an answer before our meeting > Sep. 20-21 in Vienna. > > Best regards > Rolf Rabenseifner > > ----- Original Message ----- > > From: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > > To: mpi-comments(a)mpi-forum.org > > Sent: Sunday, August 5, 2012 6:50:29 AM > > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > Dear MPI Forum committee members, > > > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 > > for your consideration. > > > > Version: MPI-3.0 Draft 2, August 2012. > > > > The URL of the version of the MPI standard: > > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > > > Page: 65 > > > > Line number: 28 > > > > Section: 3.8.1 > > > > In: > > > > 3. Point-to-Point Communication > > 3.8 Probe and Cancel > > 3.8.1 Probe > > > > Comment: > > > > It says that the source argument of MPI_Iprobe can be > > MPI_ANY_SOURCE, > > but it > > does say anything about fairness. Therefore MPI_ANY_SOURCE can lead > > to > > resource > > starvation. > > > > I think it would be better if probing would be done in a round-robin > > fashion > > when the source is MPI_ANY_SOURCE so that any MPI rank has an equal > > chance of > > having its message probed and received. > > > > Presently, the MPI standard contains nothing about which source > > should > > be probed when > > MPI_ANY_SOURCE is provided. > > > > I hope you will consider my comment. > > > > > > Sincerely, > > > > > > Sébastien Boisvert > > PhD student > > Université Laval > > > > _______________________________________________ > > mpi-comments mailing list > > mpi-comments(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert
by Richard Graham 09 Aug '12

09 Aug '12

Rolf, Thanks a lot for the help here, but this is really not needed at this stage. I have started to farm off requests to the appropriate working groups. In this case, the response will be that we will need a specific proposal for something to happen beyond MPI 3.0, as this can be either an implementation issue, or a change in long-standing semantics, which are beyond the scope of the current work. Thanks, Rich -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Rolf Rabenseifner Sent: Thursday, August 09, 2012 12:20 PM To: Main MPI Forum mailing list Subject: [Mpi-forum] Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert I try to test the proposed process for comments. This comment is about the Point-to-Point chapter. Rich is the chapter author. Here is the comment (see bottom of this email) together with my reply to the comment's author and a first proposal for solving it: All references are related to http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf Summary about the comment: ========================== The text in new MPI_IMPROBE about MPI_ANY_SOURCE does not say anything about fairness. The commentator asks for a round-robin fairness behavior. Summary of my proposal to answer this comment: ============================================== - Keep the unfair behavior as defined on p42:10-17 - Clarify this faiirness-paragraph to make clear that it also applies to MPI_ANY_SOURCE. - Add cross-references between p42:10-17, MPI_RECV and all MPI_PROBE routines to make clear that there is no fairness with MPI_ANY_SOURCE. Proposed solution: ================== All references are related to http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf mpi3.0_draft_2.pdf p29:25-31 read The receiver may specify a wildcard MPI_ANY_SOURCE value for source, and/or a wildcard MPI_ANY_TAG value for tag, indicating that any source and/or tag are acceptable. It cannot specify a wildcard value for comm. Thus, a message can be received by a receive operation only if it is addressed to the receiving process, has a matching communicator, has matching source unless source=MPI_ANY_SOURCE in the pattern, and has a matching tag unless tag=MPI_ANY_TAG in the pattern. and the following text should be added: Note that MPI makes no guarantee of fairness in the handling of communication, especially when using MPI_ANY_SOURCE; for details see the section on {\em Fairness} on page 42. mpi3.0_draft_2.pdf p42:10 read Fairness[ ] MPI makes no guarantee of fairness in the handling of communication. but should read Fairness[ ] MPI makes no guarantee of fairness in the handling of communication, e.g., when using MPI_ANY_SOURCE, MPI_WAITANY or MPI_WAITSOME in a singlethreaded process, or using MPI_RECV or MPI_MPROBE by several threads in a multithreaded process. mpi3.0_draft_2.pdf p65:16-18 (in the definition of MPI_IPROBE) read The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and returns in status the same value that would have been returned by MPI_RECV(). but should read (only the reference on the last line is added): The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and returns in status the same value that would have been returned by MPI_RECV(), see Section 3.2.4 on page 28. mpi3.0_draft_2.pdf p68:33-35 (in the definition of MPI_IMPROBE) read The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program and returns in status the same value that would have been returned by MPI_RECV. but should read (only the reference on the last line is added): The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program and returns in status the same value that would have been returned by MPI_RECV, see Section 3.2.4 on page 28. Proposed answer to the commentator (together with the proposed solution): ====================================== MPI defines to be unfair, see page 42, lines 10-17. Cross-references were missing in the MPI standard, i.e., it was not easy to detect that this paragraph on fairness also applies to MPI_ANY_SOURCE in any call (MPI_RECV, MPI_IRECV, and all versions of MPI_PROBE) The proposed solution adds the missing cross-references. For performance reasons, the MPI Forum decided not to change this "unfair" behavior. You may use other mechanisms to implement some sort of fairness. Especially the tag can be used in a cyclic way (i.e. with values between 0 and 32767) to implement some sort of fairness, but this is outside of the scope of the MPI standard. We did not add an advice to users about mechanisms to implement some sort of fairness within the application. Such an advice would go beyond the task of the MPI standard. Background (not to be part of the answer to the commentator) ============================================================ The following part of the comment > Presently, the MPI standard contains nothing about which source should > be probed when MPI_ANY_SOURCE is provided. is not fully true. The MPI standard clearly states in mpi3.0_draft_2.pdf in Section 3.5 Semantics of Point-to-Point Communication on page 42 lines 10-17 Fairness. MPI makes no guarantee of fairness in the handling of communication. Suppose that a send is posted. Then it is possible that the destination process repeatedly posts a receive that matches this send, yet the message is never received, because it is each time overtaken by another message, sent from another source. Similarly, suppose that a receive was posted by a multithreaded process. Then it is possible that messages that match this receive are repeatedly received, yet the receive is never satisfied, because it is overtaken by other receives posted at this node (by other executing threads). It is the programmer's responsibility to prevent starvation in such situations. that there is no fairness. And I expect that the MPI Forum does not want to change this statement. This section does not mention MPI_ANY_SOURCE. My proposal adds here a note on MPI_ANY_SOURCE that readers can find the Fairness paragraph when the look at all locations of MPI_ANY_SOURCE. MPI_ANY_SOURCE is defined in the text about the source rank of MPI_RECV without any reference to the Fairness paragraph, see page 29 lines 23-31. I added a reference to the Fairness paragraph to solve this lack of reference. And MPI_IPROBE and MPI_IMPROBE have own text on MPI_ANY_SOURCE. Here I would propose to add only a reference to Section 3.2.4, which defines MPI_RECV and which should contain the reference to the fairness paragraph. ---------------------- My goal was not to change anything, i.e., only to add clarifying references. Any comments about this proposal? Corrections about my wording? Agreed? Best regards Rolf ----- Forwarded Message ----- From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> To: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> Sent: Thursday, August 9, 2012 8:09:49 AM Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 Dear Mr. Boisvert, the MPI Forum will discuss your comment and will return an answer before our meeting Sep. 20-21 in Vienna. Best regards Rolf Rabenseifner ----- Original Message ----- > From: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > To: mpi-comments(a)mpi-forum.org > Sent: Sunday, August 5, 2012 6:50:29 AM > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > Dear MPI Forum committee members, > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 > for your consideration. > > Version: MPI-3.0 Draft 2, August 2012. > > The URL of the version of the MPI standard: > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > Page: 65 > > Line number: 28 > > Section: 3.8.1 > > In: > > 3. Point-to-Point Communication > 3.8 Probe and Cancel > 3.8.1 Probe > > Comment: > > It says that the source argument of MPI_Iprobe can be MPI_ANY_SOURCE, > but it > does say anything about fairness. Therefore MPI_ANY_SOURCE can lead to > resource > starvation. > > I think it would be better if probing would be done in a round-robin > fashion > when the source is MPI_ANY_SOURCE so that any MPI rank has an equal > chance of > having its message probed and received. > > Presently, the MPI standard contains nothing about which source should > be probed when > MPI_ANY_SOURCE is provided. > > I hope you will consider my comment. > > > Sincerely, > > > Sébastien Boisvert > PhD student > Université Laval > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Fairness of MPI_ANY_SOURCE - MPI-3.0 Draft2 comment by Sebastien Boisvert
by Rolf Rabenseifner 09 Aug '12

09 Aug '12

I try to test the proposed process for comments. This comment is about the Point-to-Point chapter. Rich is the chapter author. Here is the comment (see bottom of this email) together with my reply to the comment's author and a first proposal for solving it: All references are related to http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf Summary about the comment: ========================== The text in new MPI_IMPROBE about MPI_ANY_SOURCE does not say anything about fairness. The commentator asks for a round-robin fairness behavior. Summary of my proposal to answer this comment: ============================================== - Keep the unfair behavior as defined on p42:10-17 - Clarify this faiirness-paragraph to make clear that it also applies to MPI_ANY_SOURCE. - Add cross-references between p42:10-17, MPI_RECV and all MPI_PROBE routines to make clear that there is no fairness with MPI_ANY_SOURCE. Proposed solution: ================== All references are related to http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf mpi3.0_draft_2.pdf p29:25-31 read The receiver may specify a wildcard MPI_ANY_SOURCE value for source, and/or a wildcard MPI_ANY_TAG value for tag, indicating that any source and/or tag are acceptable. It cannot specify a wildcard value for comm. Thus, a message can be received by a receive operation only if it is addressed to the receiving process, has a matching communicator, has matching source unless source=MPI_ANY_SOURCE in the pattern, and has a matching tag unless tag=MPI_ANY_TAG in the pattern. and the following text should be added: Note that MPI makes no guarantee of fairness in the handling of communication, especially when using MPI_ANY_SOURCE; for details see the section on {\em Fairness} on page 42. mpi3.0_draft_2.pdf p42:10 read Fairness[ ] MPI makes no guarantee of fairness in the handling of communication. but should read Fairness[ ] MPI makes no guarantee of fairness in the handling of communication, e.g., when using MPI_ANY_SOURCE, MPI_WAITANY or MPI_WAITSOME in a singlethreaded process, or using MPI_RECV or MPI_MPROBE by several threads in a multithreaded process. mpi3.0_draft_2.pdf p65:16-18 (in the definition of MPI_IPROBE) read The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and returns in status the same value that would have been returned by MPI_RECV(). but should read (only the reference on the last line is added): The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program, and returns in status the same value that would have been returned by MPI_RECV(), see Section 3.2.4 on page 28. mpi3.0_draft_2.pdf p68:33-35 (in the definition of MPI_IMPROBE) read The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program and returns in status the same value that would have been returned by MPI_RECV. but should read (only the reference on the last line is added): The call matches the same message that would have been received by a call to MPI_RECV(..., source, tag, comm, status) executed at the same point in the program and returns in status the same value that would have been returned by MPI_RECV, see Section 3.2.4 on page 28. Proposed answer to the commentator (together with the proposed solution): ====================================== MPI defines to be unfair, see page 42, lines 10-17. Cross-references were missing in the MPI standard, i.e., it was not easy to detect that this paragraph on fairness also applies to MPI_ANY_SOURCE in any call (MPI_RECV, MPI_IRECV, and all versions of MPI_PROBE) The proposed solution adds the missing cross-references. For performance reasons, the MPI Forum decided not to change this "unfair" behavior. You may use other mechanisms to implement some sort of fairness. Especially the tag can be used in a cyclic way (i.e. with values between 0 and 32767) to implement some sort of fairness, but this is outside of the scope of the MPI standard. We did not add an advice to users about mechanisms to implement some sort of fairness within the application. Such an advice would go beyond the task of the MPI standard. Background (not to be part of the answer to the commentator) ============================================================ The following part of the comment > Presently, the MPI standard contains nothing about which source should > be probed when MPI_ANY_SOURCE is provided. is not fully true. The MPI standard clearly states in mpi3.0_draft_2.pdf in Section 3.5 Semantics of Point-to-Point Communication on page 42 lines 10-17 Fairness. MPI makes no guarantee of fairness in the handling of communication. Suppose that a send is posted. Then it is possible that the destination process repeatedly posts a receive that matches this send, yet the message is never received, because it is each time overtaken by another message, sent from another source. Similarly, suppose that a receive was posted by a multithreaded process. Then it is possible that messages that match this receive are repeatedly received, yet the receive is never satisfied, because it is overtaken by other receives posted at this node (by other executing threads). It is the programmer's responsibility to prevent starvation in such situations. that there is no fairness. And I expect that the MPI Forum does not want to change this statement. This section does not mention MPI_ANY_SOURCE. My proposal adds here a note on MPI_ANY_SOURCE that readers can find the Fairness paragraph when the look at all locations of MPI_ANY_SOURCE. MPI_ANY_SOURCE is defined in the text about the source rank of MPI_RECV without any reference to the Fairness paragraph, see page 29 lines 23-31. I added a reference to the Fairness paragraph to solve this lack of reference. And MPI_IPROBE and MPI_IMPROBE have own text on MPI_ANY_SOURCE. Here I would propose to add only a reference to Section 3.2.4, which defines MPI_RECV and which should contain the reference to the fairness paragraph. ---------------------- My goal was not to change anything, i.e., only to add clarifying references. Any comments about this proposal? Corrections about my wording? Agreed? Best regards Rolf ----- Forwarded Message ----- From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> To: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> Sent: Thursday, August 9, 2012 8:09:49 AM Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 Dear Mr. Boisvert, the MPI Forum will discuss your comment and will return an answer before our meeting Sep. 20-21 in Vienna. Best regards Rolf Rabenseifner ----- Original Message ----- > From: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > To: mpi-comments(a)mpi-forum.org > Sent: Sunday, August 5, 2012 6:50:29 AM > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > Dear MPI Forum committee members, > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 > for your consideration. > > Version: MPI-3.0 Draft 2, August 2012. > > The URL of the version of the MPI standard: > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > Page: 65 > > Line number: 28 > > Section: 3.8.1 > > In: > > 3. Point-to-Point Communication > 3.8 Probe and Cancel > 3.8.1 Probe > > Comment: > > It says that the source argument of MPI_Iprobe can be MPI_ANY_SOURCE, > but it > does say anything about fairness. Therefore MPI_ANY_SOURCE can lead to > resource > starvation. > > I think it would be better if probing would be done in a round-robin > fashion > when the source is MPI_ANY_SOURCE so that any MPI rank has an equal > chance of > having its message probed and received. > > Presently, the MPI standard contains nothing about which source should > be probed when > MPI_ANY_SOURCE is provided. > > I hope you will consider my comment. > > > Sincerely, > > > Sébastien Boisvert > PhD student > Université Laval > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Rolf Rabenseifner 08 Aug '12

08 Aug '12

Rich and Jeff and chapter authors, yes, I looked on the two points (1. handling all comments, and 2. missing people on comments list) and additionally on 3. to act as soon as possible, i.e. not to waste discussion time; 4. to have a process that may work with "any" number of comments; 5. informing/involving the whole forum, because at the end, the whole forum must vote on MPI-3.0 and we do not want late discussions one day before voting; 6. works in vacation time because comments are diuscussed as early as possible and not after Based on the proposal and the discussion and the up to now small number of comments, I propose the following process: 1. Rich puts all chapter authors (not the whole chapter commitees) on the comments list. 2. When a comment on MPI-3.0 draft comes in (allowed until Sep. 6) then - the involved chapter author, - or any forum member, - (or Rich if the chapter author does not take the job) replies to the comment's author that the Forum will discuss his/her comment and will return with a reply, and forwards the comment to "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> together with a meaningful subject mentioning also the comment's author, here e.g. "Fairness of MPI_ANY_SOURCE - Sebastien Boisvert" This helps match the two tracks in mpi-comments (typically only two mails) and mpi-forum (full internal discussion) email lists. 3. The comment is discussed on mpi-forum(a)lists.mpi-forum.org and a decision is done depending on our typical rules - small things are directly agreed by the chapter author, - small corrections are agreed by the chapter committee, - larger clarifications maybe discussed and agreed by the whole forum. Normally, corrections need broad consensus to be added to the document. 4. After consensus, a clear MPI-3.0 draft Aug. 02, 2012 page line reads ... but should read ... must be available. 5. This answer is sent by the responsible chapter author to the comment's author with CC to mpi-comments(a)mpi-forum.org (This 5th step also requires that the chapter authors are member of the comments list) All these mails should be done before Sep. 10, 2012. If there is real need for a telecon, it is scheduled on Sep. 10. All decided changes go directly into approved svn. Decision on the telecon must go until Sep 11 into the apporved trunk. Final draft version is done on Sep. 12 and published to the forum. Because all chapter authors are involved and there is only one "bottleneck" in item 1, this process should work for any number (less 100 :-) of comments. Rich, okay so? If yes, we should start with the existing comments. If no, then please propose another clear process (i.e. full text) which works in vacation time (e.g., I will be most time off-line in Sep. 3-14) and all the other constraints mentioned at the beginning of this email. Best regards Rolf ----- Original Message ----- > From: "Richard Graham" <richardg(a)mellanox.com> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, August 6, 2012 8:39:52 PM > Subject: Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, > August 2012 > Comments in line: > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Jeff > Squyres > Sent: Monday, August 06, 2012 8:40 PM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] Process for handling of such comments - Fwd: > [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > I think Rolf's points were twofold: > > 1. How do we track the comments to ensure that we don't lose any / > consider every one? > [rich] I plan to look through the archives after the 6th, and to > forward comments to the relevant wg's. Right now this is simple, but > if we start to get a lot of comments, will have to get organized a bit > better. > > > 2. If the chapter authors are not subscribed to the mpi-comments list, > then they won't even know if their chapter got a comment. > [rich] We can forward mail messages. > > Rich > > > On Aug 6, 2012, at 1:20 PM, Richard Graham wrote: > > > The plan is to go over the comments and make any changes we agree on > > by the 12th, giving people a week to go over the document before the > > final votes. > > > > Small edits will go to chapter committees for their review, and if > > there are large items, we will need to have a telecom on the 10th of > > Sept to decide if and how to respond. > > > > So far, there have been only 1-2 minor comments. > > > > Rich > > > > -----Original Message----- > > From: mpi-forum-bounces(a)lists.mpi-forum.org > > [mailto:[email protected]] On Behalf Of Rolf > > Rabenseifner > > Sent: Monday, August 06, 2012 2:01 PM > > To: Main MPI Forum mailing list > > Subject: [Mpi-forum] Process for handling of such comments - Fwd: > > [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > > > Rich and Jeff and chapter authors, > > > > Rich, > > how do we process the incoming comments. > > Should we discuss such comments on > > > > "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org>; > > > > and after having a result, replying to the comment with direct > > email > > to the author of the comment with a CC to mpi-comments(a)mpi-forum.org > > ? > > > > Everybody can be the starter of such discussion by forwarding such > > a > > comments-email to the mpi-forum list together with a meaningful > > subject mentioning also the comment's author, here e.g. > > > > "Fairness of MPI_ANY_SOURCE - Sebastien Boisvert" > > > > This helps match the two tracks in mpi-comments (typically only two > > mails) and mpi-forum (full internal discussion) email lists. > > > > Chapter authors, > > if nobody else started such a discussion, then the chapter author > > must start the discussion. > > If there is no specific chapter, then Rich as MPI-3.0 chair takes > > this role. > > > > Jeff, > > are all chapter authors member of the comments list? > > > > Rich, what do you think about this process proposal. > > You started the idea with public comment, therefore I ask you > > directly to send out a process rule that we all should use. > > > > Best regards > > Rolf > > > > PS: All, please do not use this track for discussing the > > content of the comment. > > > > > > ----- Forwarded Message ----- > > From: "Sébastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > > To: mpi-comments(a)mpi-forum.org > > Sent: Sunday, August 5, 2012 6:50:29 AM > > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > > > Dear MPI Forum committee members, > > > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 > > for your consideration. > > > > Version: MPI-3.0 Draft 2, August 2012. > > > > The URL of the version of the MPI standard: > > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > > > Page: 65 > > > > Line number: 28 > > > > Section: 3.8.1 > > > > In: > > > > 3. Point-to-Point Communication > > 3.8 Probe and Cancel > > 3.8.1 Probe > > > > Comment: > > > > It says that the source argument of MPI_Iprobe can be > > MPI_ANY_SOURCE, but it does say anything about fairness. Therefore > > MPI_ANY_SOURCE can lead to resource starvation. > > > > I think it would be better if probing would be done in a round-robin > > fashion when the source is MPI_ANY_SOURCE so that any MPI rank has > > an equal chance of having its message probed and received. > > > > Presently, the MPI standard contains nothing about which source > > should be probed when MPI_ANY_SOURCE is provided. > > > > I hope you will consider my comment. > > > > > > Sincerely, > > > > > > Sébastien Boisvert > > PhD student > > Université Laval > > > > _______________________________________________ > > mpi-comments mailing list > > mpi-comments(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > _______________________________________________ > > 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 > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Richard Graham 06 Aug '12

06 Aug '12

Comments in line: -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Monday, August 06, 2012 8:40 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 I think Rolf's points were twofold: 1. How do we track the comments to ensure that we don't lose any / consider every one? [rich] I plan to look through the archives after the 6th, and to forward comments to the relevant wg's. Right now this is simple, but if we start to get a lot of comments, will have to get organized a bit better. 2. If the chapter authors are not subscribed to the mpi-comments list, then they won't even know if their chapter got a comment. [rich] We can forward mail messages. Rich On Aug 6, 2012, at 1:20 PM, Richard Graham wrote: > The plan is to go over the comments and make any changes we agree on by the 12th, giving people a week to go over the document before the final votes. > > Small edits will go to chapter committees for their review, and if there are large items, we will need to have a telecom on the 10th of Sept to decide if and how to respond. > > So far, there have been only 1-2 minor comments. > > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Rolf > Rabenseifner > Sent: Monday, August 06, 2012 2:01 PM > To: Main MPI Forum mailing list > Subject: [Mpi-forum] Process for handling of such comments - Fwd: > [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > Rich and Jeff and chapter authors, > > Rich, > how do we process the incoming comments. > Should we discuss such comments on > > "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org>; > > and after having a result, replying to the comment with direct email > to the author of the comment with a CC to mpi-comments(a)mpi-forum.org ? > > Everybody can be the starter of such discussion by forwarding such a > comments-email to the mpi-forum list together with a meaningful > subject mentioning also the comment's author, here e.g. > > "Fairness of MPI_ANY_SOURCE - Sebastien Boisvert" > > This helps match the two tracks in mpi-comments (typically only two > mails) and mpi-forum (full internal discussion) email lists. > > Chapter authors, > if nobody else started such a discussion, then the chapter author > must start the discussion. > If there is no specific chapter, then Rich as MPI-3.0 chair takes > this role. > > Jeff, > are all chapter authors member of the comments list? > > Rich, what do you think about this process proposal. > You started the idea with public comment, therefore I ask you directly to send out a process rule that we all should use. > > Best regards > Rolf > > PS: All, please do not use this track for discussing the > content of the comment. > > > ----- Forwarded Message ----- > From: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > To: mpi-comments(a)mpi-forum.org > Sent: Sunday, August 5, 2012 6:50:29 AM > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > Dear MPI Forum committee members, > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 for your consideration. > > Version: MPI-3.0 Draft 2, August 2012. > > The URL of the version of the MPI standard: > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > Page: 65 > > Line number: 28 > > Section: 3.8.1 > > In: > > 3. Point-to-Point Communication > 3.8 Probe and Cancel > 3.8.1 Probe > > Comment: > > It says that the source argument of MPI_Iprobe can be MPI_ANY_SOURCE, but it does say anything about fairness. Therefore MPI_ANY_SOURCE can lead to resource starvation. > > I think it would be better if probing would be done in a round-robin fashion when the source is MPI_ANY_SOURCE so that any MPI rank has an equal chance of having its message probed and received. > > Presently, the MPI standard contains nothing about which source should be probed when MPI_ANY_SOURCE is provided. > > I hope you will consider my comment. > > > Sincerely, > > > Sï¿½bastien Boisvert > PhD student > Universitï¿½ Laval > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > 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] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Jeff Squyres 06 Aug '12

06 Aug '12

In that case, you won't be able to reply back to the comments list (because you -- as an individual email address -- won't be subscribed to the comments list). On Aug 6, 2012, at 1:51 PM, Rajeev Thakur wrote: > Maybe one of the subscribers to the comments list should be "mpi-forum(a)lists.mpi-forum.org" > > On Aug 6, 2012, at 12:14 PM, Richard Graham wrote: > >> Actually, >> Very few are subscribed to the mailing list - 38 at this stage, with almost none being active forum members. >> >> Rich >> >> -----Original Message----- >> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres >> Sent: Monday, August 06, 2012 2:30 PM >> To: Main MPI Forum mailing list >> Subject: Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 >> >> On Aug 6, 2012, at 6:59 AM, Rolf Rabenseifner wrote: >> >>> Jeff, >>> are all chapter authors member of the comments list? >> >> I do not know; Rich is the owner of the comments list -- I cannot see the subscribers. I suspect not, however. >> >> -- >> 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 >> >> _______________________________________________ >> 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] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Rajeev Thakur 06 Aug '12

06 Aug '12

Maybe one of the subscribers to the comments list should be "mpi-forum(a)lists.mpi-forum.org" On Aug 6, 2012, at 12:14 PM, Richard Graham wrote: > Actually, > Very few are subscribed to the mailing list - 38 at this stage, with almost none being active forum members. > > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres > Sent: Monday, August 06, 2012 2:30 PM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > On Aug 6, 2012, at 6:59 AM, Rolf Rabenseifner wrote: > >> Jeff, >> are all chapter authors member of the comments list? > > I do not know; Rich is the owner of the comments list -- I cannot see the subscribers. I suspect not, however. > > -- > 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 > > _______________________________________________ > 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] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Jeff Squyres 06 Aug '12

06 Aug '12

I think Rolf's points were twofold: 1. How do we track the comments to ensure that we don't lose any / consider every one? 2. If the chapter authors are not subscribed to the mpi-comments list, then they won't even know if their chapter got a comment. On Aug 6, 2012, at 1:20 PM, Richard Graham wrote: > The plan is to go over the comments and make any changes we agree on by the 12th, giving people a week to go over the document before the final votes. > > Small edits will go to chapter committees for their review, and if there are large items, we will need to have a telecom on the 10th of Sept to decide if and how to respond. > > So far, there have been only 1-2 minor comments. > > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Rolf Rabenseifner > Sent: Monday, August 06, 2012 2:01 PM > To: Main MPI Forum mailing list > Subject: [Mpi-forum] Process for handling of such comments - Fwd: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > Rich and Jeff and chapter authors, > > Rich, > how do we process the incoming comments. > Should we discuss such comments on > > "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org>; > > and after having a result, replying to the comment with direct email > to the author of the comment with a CC to mpi-comments(a)mpi-forum.org ? > > Everybody can be the starter of such discussion by > forwarding such a comments-email to the mpi-forum list > together with a meaningful subject mentioning also the > comment's author, here e.g. > > "Fairness of MPI_ANY_SOURCE - Sebastien Boisvert" > > This helps match the two tracks in mpi-comments (typically only > two mails) and mpi-forum (full internal discussion) email lists. > > Chapter authors, > if nobody else started such a discussion, then the > chapter author must start the discussion. > If there is no specific chapter, then Rich as MPI-3.0 chair > takes this role. > > Jeff, > are all chapter authors member of the comments list? > > Rich, what do you think about this process proposal. > You started the idea with public comment, therefore I ask you directly to send out a process rule that we all should use. > > Best regards > Rolf > > PS: All, please do not use this track for discussing the > content of the comment. > > > ----- Forwarded Message ----- > From: "Sï¿½bastien Boisvert" <sebastien.boisvert.3(a)ulaval.ca> > To: mpi-comments(a)mpi-forum.org > Sent: Sunday, August 5, 2012 6:50:29 AM > Subject: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 > > Dear MPI Forum committee members, > > I would like to submit a comment on the MPI-3.0 Draft 2, August 2012 for your consideration. > > Version: MPI-3.0 Draft 2, August 2012. > > The URL of the version of the MPI standard: > http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf > > Page: 65 > > Line number: 28 > > Section: 3.8.1 > > In: > > 3. Point-to-Point Communication > 3.8 Probe and Cancel > 3.8.1 Probe > > Comment: > > It says that the source argument of MPI_Iprobe can be MPI_ANY_SOURCE, but it does say anything about fairness. Therefore MPI_ANY_SOURCE can lead to resource starvation. > > I think it would be better if probing would be done in a round-robin fashion when the source is MPI_ANY_SOURCE so that any MPI rank has an equal chance of having its message probed and received. > > Presently, the MPI standard contains nothing about which source should be probed when MPI_ANY_SOURCE is provided. > > I hope you will consider my comment. > > > Sincerely, > > > Sï¿½bastien Boisvert > PhD student > Universitï¿½ Laval > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > 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