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

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by George Bosilca 15 Aug '12

15 Aug '12

In other terms it depends on what you prefer to understand by fairness. geeks: http://en.wikipedia.org/wiki/Unbounded_nondeterminism otherwise: http://dictionary.reference.com/browse/fairness george. On Aug 15, 2012, at 21:29 , William Gropp wrote: > This is a good point. Using the Testsome or Waitsome interface permits an application to respond fairly without burdening the implementation with any particular fairness definition. Not every code can be conveniently written this way, but it addresses many needs. > > As has been noted, specifying the exact meaning of fairness (e.g., round robin) may have serious performance impact, as an implementation may make fair progress but in a different, possibly non-deterministic, order. Even if "fairness" is provided, it should be defined in terms of the essential properties, not a particular implementation that happens to have those properties. > > 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 15, 2012, at 8:54 AM, Jim Dinan wrote: > >> Hi Sebastien, >> >> Something to consider in addition to probe is that fairness semantics are also relevant to test/wait operations that take arrays of requests. It may make the most sense to attach a fairness attribute to communication contexts (communicators and windows) to provide more flexibility. This could already be done by an MPI implementation through an info key on a communicator/window, however implementations need not support all info keys and fairness could be a requirement for applications that rely on it. >> >> Cheers, >> ~Jim. >> >> On 8/15/12 10:19 AM, Sï¿½bastien Boisvert wrote: >>> Maybe there could be something like MPI_Init_fairness which could either >>> be MPI_FAIRNESS_NO (the current behavior) or MPI_FAIRNESS_YES (which >>> would do round-robin reception). >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by William Gropp 15 Aug '12

15 Aug '12

This is a good point. Using the Testsome or Waitsome interface permits an application to respond fairly without burdening the implementation with any particular fairness definition. Not every code can be conveniently written this way, but it addresses many needs. As has been noted, specifying the exact meaning of fairness (e.g., round robin) may have serious performance impact, as an implementation may make fair progress but in a different, possibly non-deterministic, order. Even if "fairness" is provided, it should be defined in terms of the essential properties, not a particular implementation that happens to have those properties. 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 15, 2012, at 8:54 AM, Jim Dinan wrote: > Hi Sebastien, > > Something to consider in addition to probe is that fairness semantics are also relevant to test/wait operations that take arrays of requests. It may make the most sense to attach a fairness attribute to communication contexts (communicators and windows) to provide more flexibility. This could already be done by an MPI implementation through an info key on a communicator/window, however implementations need not support all info keys and fairness could be a requirement for applications that rely on it. > > Cheers, > ~Jim. > > On 8/15/12 10:19 AM, Sï¿½bastien Boisvert wrote: >> Maybe there could be something like MPI_Init_fairness which could either >> be MPI_FAIRNESS_NO (the current behavior) or MPI_FAIRNESS_YES (which >> would do round-robin reception). > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Jim Dinan 15 Aug '12

15 Aug '12

Hi Sebastien, Something to consider in addition to probe is that fairness semantics are also relevant to test/wait operations that take arrays of requests. It may make the most sense to attach a fairness attribute to communication contexts (communicators and windows) to provide more flexibility. This could already be done by an MPI implementation through an info key on a communicator/window, however implementations need not support all info keys and fairness could be a requirement for applications that rely on it. Cheers, ~Jim. On 8/15/12 10:19 AM, Sï¿½bastien Boisvert wrote: > Maybe there could be something like MPI_Init_fairness which could either > be MPI_FAIRNESS_NO (the current behavior) or MPI_FAIRNESS_YES (which > would do round-robin reception).

1 0

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Richard Graham 15 Aug '12

15 Aug '12

Sï¿½bastien, To get involved, see meetings.mpi-forum.org, where there are mailing lists you can join, as well as meeting details. The most effective way to participate it to get involved in person. Rich -----Original Message----- From: mpi-comments-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Sï¿½bastien Boisvert Sent: Wednesday, August 15, 2012 11:20 AM To: mpi-comments(a)lists.mpi-forum.org Subject: Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012 Hello Richard, I really agree that this is a big change. And I am aware that there is no fairness by design [1]. In Open-MPI, George Bosilca provided a patch [2], which I modified [3] for a round-robin policy and tested [4]. For threading, there is MPI_Init_thread that tells MPI if one or more thread will be spawned and if one or more will make MPI calls. Maybe there could be something like MPI_Init_fairness which could either be MPI_FAIRNESS_NO (the current behavior) or MPI_FAIRNESS_YES (which would do round-robin reception). How can I get involved ? [1] http://www.mcs.anl.gov/research/projects/mpi/tutorial/gropp/node92.html [2] http://www.open-mpi.org/community/lists/devel/att-9769/iprobe_starvation.pa… [3] http://www.open-mpi.org/community/lists/devel/att-9770/iprobe_starvation_fi… [4] http://www.open-mpi.org/community/lists/devel/2011/09/9770.php Richard Graham a ï¿½crit : > Sï¿½bastien, > Thanks you for sending in this request, this is truly appreciated. > The propose change is a large change to the standard, even though it may not seem so at a first glance. Today the standard is explicit about lack of fairness, and we would have to think through in detail on the broad impact of such a change. So, this does not the sort of item we can address for MPI 3.0. > However, if you would like to push a change like this into MPI, this can be addressed for the following version of the standard. What I would suggest, if this is something that you really think belongs in the standard, that you either get involved directly in the process (the standardization effort is open to all), or find someone the is involved to actively push such a request. As I said, this is a non-trivial change, so that both API changes (if any) and implementation issues need to be addressed. Please let me know if you need help with figuring out how to get involved. > > Thanks again, > Rich > > -----Original Message----- > From: Sï¿½bastien Boisvert [mailto:[email protected]] > Sent: Tuesday, August 14, 2012 9:47 AM > To: mpi-comments(a)mpi-forum.org > 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 > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments _______________________________________________ mpi-comments mailing list mpi-comments(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Sébastien Boisvert 15 Aug '12

15 Aug '12

Hello Richard, I really agree that this is a big change. And I am aware that there is no fairness by design [1]. In Open-MPI, George Bosilca provided a patch [2], which I modified [3] for a round-robin policy and tested [4]. For threading, there is MPI_Init_thread that tells MPI if one or more thread will be spawned and if one or more will make MPI calls. Maybe there could be something like MPI_Init_fairness which could either be MPI_FAIRNESS_NO (the current behavior) or MPI_FAIRNESS_YES (which would do round-robin reception). How can I get involved ? [1] http://www.mcs.anl.gov/research/projects/mpi/tutorial/gropp/node92.html [2] http://www.open-mpi.org/community/lists/devel/att-9769/iprobe_starvation.pa… [3] http://www.open-mpi.org/community/lists/devel/att-9770/iprobe_starvation_fi… [4] http://www.open-mpi.org/community/lists/devel/2011/09/9770.php Richard Graham a ï¿½crit : > Sï¿½bastien, > Thanks you for sending in this request, this is truly appreciated. > The propose change is a large change to the standard, even though it may not seem so at a first glance. Today the standard is explicit about lack of fairness, and we would have to think through in detail on the broad impact of such a change. So, this does not the sort of item we can address for MPI 3.0. > However, if you would like to push a change like this into MPI, this can be addressed for the following version of the standard. What I would suggest, if this is something that you really think belongs in the standard, that you either get involved directly in the process (the standardization effort is open to all), or find someone the is involved to actively push such a request. As I said, this is a non-trivial change, so that both API changes (if any) and implementation issues need to be addressed. Please let me know if you need help with figuring out how to get involved. > > Thanks again, > Rich > > -----Original Message----- > From: Sï¿½bastien Boisvert [mailto:[email protected]] > Sent: Tuesday, August 14, 2012 9:47 AM > To: mpi-comments(a)mpi-forum.org > 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 > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Post MPI 3.0 suggestion
by Stephen Booth 15 Aug '12

15 Aug '12

This comment comes under the following: > - Wishes for additional enhancements or new functionality > to be taken into account after 3.0 is published. I think there are some cases where persistent collective requests would make sense. Specifically as an opportunity to allow auto-tuning of the implementation based on the call parameters. The most compelling justification for this is to optimise AlltoAllv operations. Unlike the AlltoAll operation these cannot easily use tree based optimisations for small message sizes as each process only knows that part of the communication pattern they are directly involved with. However if the same communication pattern is to be re-used multiple times as a persistent request then the init call (which should itself be collective) could take the time to auto-tune a communication schedule best suited to the specified parameters. Stephen -- ====================================================================== |epcc| Dr Stephen P Booth Principal Architect |epcc| |epcc| s.booth(a)epcc.ed.ac.uk Phone 0131 650 5746 |epcc| ====================================================================== -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [Mpi-comments] One comment on MPI-3.0 Draft 2, August 2012
by Richard Graham 15 Aug '12

15 Aug '12

Sï¿½bastien, Thanks you for sending in this request, this is truly appreciated. The propose change is a large change to the standard, even though it may not seem so at a first glance. Today the standard is explicit about lack of fairness, and we would have to think through in detail on the broad impact of such a change. So, this does not the sort of item we can address for MPI 3.0. However, if you would like to push a change like this into MPI, this can be addressed for the following version of the standard. What I would suggest, if this is something that you really think belongs in the standard, that you either get involved directly in the process (the standardization effort is open to all), or find someone the is involved to actively push such a request. As I said, this is a non-trivial change, so that both API changes (if any) and implementation issues need to be addressed. Please let me know if you need help with figuring out how to get involved. Thanks again, Rich -----Original Message----- From: Sï¿½bastien Boisvert [mailto:[email protected]] Sent: Tuesday, August 14, 2012 9:47 AM To: mpi-comments(a)mpi-forum.org 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

1 0

Re: [Mpi-comments] MPI_Is_thread_main: usage allowed for any thread in MPI_THREAD_FUNNELED mode?
by Richard Graham 15 Aug '12

15 Aug '12

Philippe, Thank you very much for taking the time to send in this comment - this is greatly appreciated. The request is a good request, and the working group in charge of this particular chapter has agreed to look into this. However, this will not make it into MPI 3.0, but is targeted for the following MPI. We have to carefully check the full list of affected routines, and do not have the time to do this correctly before MPI 3.0 is slated to be voted on. Thanks again, Rich -----Original Message----- From: Philippe Wautelet [mailto:[email protected]] Sent: Tuesday, August 14, 2012 10:12 AM To: mpi-comments(a)mpi-forum.org Subject: [Mpi-comments] MPI_Is_thread_main: usage allowed for any thread in MPI_THREAD_FUNNELED mode? Dear all, It is not clear to me if I am allowed to make calls to MPI_Is_thread_main from any thread if I initialized MPI with the MPI_THREAD_FUNNELED mode. For this mode, the norm says: "the application must ensure that only the main thread makes MPI calls" (page 384, lines 46-47) Therefore, a call to MPI_Is_thread_main should be incorrect. But in this case, how can I determine which thread is the main one? Or, maybe, some MPI calls could be explicitly allowed to be made by any thread? Best regards, Philippe Wautelet -------------------------------------------------------------------- Philippe Wautelet (Research Engineer) wautelet(a)idris.fr Tel. : 01 69 35 85 76 Fax : 01 69 85 37 75 IDRIS, Batiment 506, BP 167, 91403 ORSAY Cedex, France Prof. website : http://www.idris.fr Private website : http://www.fractalzone.be -------------------------------------------------------------------- _______________________________________________ mpi-comments mailing list mpi-comments(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

Re: [Mpi-comments] More on "MPI-3.0 public draft and call for comments"
by Richard Graham 14 Aug '12

14 Aug '12

Fernando, First, thanks a lot for responding to the request for information - we really appreciate this. Comments in line. Thanks, Rich -----Original Message----- From: mpi-comments-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Fernando G. Tinetti Sent: Friday, August 10, 2012 9:53 AM To: mpi-comments(a)mpi-forum.org Subject: [Mpi-comments] More on "MPI-3.0 public draft and call for comments" Hi, I'm commenting/suggesting some details about http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf because I received the e-mail from " Rolf Rabenseifner <rabenseifner(a)hlrs.de> to: fernando(a)info.unlp.edu.ar subject: MPI-3.0 public draft and call for comments " However, I did not receive any reply to my previous comment/question. Anyway, I'll make some extra comments, including the previous one: 1) I read at the end of page ii: " c 1993, 1994, 1995, 1996, 1997, 2008, 2009, 2012 University of Tennessee, Knoxville, Tennessee. Permission to copy without fee all or part of this material is granted, provided the University of Tennessee copyright notice and the title of this document appear, and notice is given that copying is by permission of the University of Tennessee. " Is it right? If so, could you give a short explanation (or a link to) about the reason/s? [rich] For historical reasons. The first copyright was owned by the University of Tennessee, as it helped start the forum in the first place, with Professor Dongarra being co-chair of the MPI-1 effort. 2) Given that of the "MPI: A Message-Passing Interface Standard" is from the "Message Passing Interface Forum" (page i in the .pdf) a minimum explanation of what the forum is and how it has evolved is in order. There are some explanations in pages iii-iv, references to MPI Forum, MPI-2 Forum (pp. iii, xxi, xxiv), and MPI-3 Forum (p. xxix) and I think it is not clear how those forums are made up e.g. the meeting itself is the Forum? The text at page 2 "These meetings and the email discussion together constituted the MPI Forum, membership of which has been open to all members of the high performance computing community." is clear about the 1993 decision, but I did not see a clear reference to the current Forum definition, Forum (committee/s) members, etc. I would like to see an informal MPI Forum evolution such as that given for MPI in pp. iii-iv. [rich] Look at meetings.mpi-forum.org - the current structure is described there. Membership and voting rights ebb and flow, as this is a voluntary organization, with organizational voting rights determined solely by participation at the Forum meetings. 3) I suggest a minor change in the text in p. 1 from " The goal of the Message-Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, e fficient, and flexible standard for message passing. A complete list of goals follows. " to " The goal of the Message-Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, e fficient, and flexible standard for message passing. A complete list of goals follows. " since I think the complete list is part of the paragraph defining goals of MPI. [rich] Thanks for the suggestion. In general, we try to avoid such sweeping statements, unless they add things to the standard that are not present in other parts of the document. We have found that with such a large document, when the standard moves forward it is too easy to miss such broad statements when the standard is being changed, producing inconsistencies in the document. Best regards, Fernando. --- La parte gris de las zapatillas es bien resbalosa, con ï¿½sas voy como Flash por la baranda de la escalera. (Santi, 7 aï¿½os) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ mpi-comments mailing list mpi-comments(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments

1 0

More on "MPI-3.0 public draft and call for comments"
by Fernando G. Tinetti 10 Aug '12

10 Aug '12

Hi, I'm commenting/suggesting some details about http://meetings.mpi-forum.org/mpi3.0_draft_2.pdf because I received the e-mail from " Rolf Rabenseifner <rabenseifner(a)hlrs.de> to: fernando(a)info.unlp.edu.ar subject: MPI-3.0 public draft and call for comments " However, I did not receive any reply to my previous comment/question. Anyway, I'll make some extra comments, including the previous one: 1) I read at the end of page ii: " c 1993, 1994, 1995, 1996, 1997, 2008, 2009, 2012 University of Tennessee, Knoxville, Tennessee. Permission to copy without fee all or part of this material is granted, provided the University of Tennessee copyright notice and the title of this document appear, and notice is given that copying is by permission of the University of Tennessee. " Is it right? If so, could you give a short explanation (or a link to) about the reason/s? 2) Given that of the "MPI: A Message-Passing Interface Standard" is from the "Message Passing Interface Forum" (page i in the .pdf) a minimum explanation of what the forum is and how it has evolved is in order. There are some explanations in pages iii-iv, references to MPI Forum, MPI-2 Forum (pp. iii, xxi, xxiv), and MPI-3 Forum (p. xxix) and I think it is not clear how those forums are made up e.g. the meeting itself is the Forum? The text at page 2 "These meetings and the email discussion together constituted the MPI Forum, membership of which has been open to all members of the high performance computing community." is clear about the 1993 decision, but I did not see a clear reference to the current Forum definition, Forum (committee/s) members, etc. I would like to see an informal MPI Forum evolution such as that given for MPI in pp. iii-iv. 3) I suggest a minor change in the text in p. 1 from " The goal of the Message-Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing. A complete list of goals follows. " to " The goal of the Message-Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing. A complete list of goals follows. " since I think the complete list is part of the paragraph defining goals of MPI. Best regards, Fernando. --- La parte gris de las zapatillas es bien resbalosa, con ï¿½sas voy como Flash por la baranda de la escalera. (Santi, 7 aï¿½os) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0