From erezh at [hidden] Mon Jun 1 12:43:13 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 1 Jun 2009 10:43:13 -0700 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: <12B00F4B-6D9F-4292-8E72-08B0ACF054F9@illinois.edu> Message-ID: <6B68D01C00C9994A8E150183E62A119E855F27321F@NA-EXMSG-C105.redmond.corp.microsoft.com> With this feedback of my distinguish colleagues, I don't see any point of perusing this proposal and I will be withdrawing this ticket in the next mpi forum meeting. Thanks, .Erez From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Wednesday, May 27, 2009 11:37 AM To: MPI 2.2 Cc: Main MPI Forum mailing list Subject: Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 This is an example of why we have two votes - to give everyone a chance to take a second look at the issues. I'll note that the 17-10 (counting no's and abstains together) is worrisome; while a majority vote is the rule, a good standard will make a compelling argument for each feature. The process here would normally be to have a debate and then the second vote. However, for MPI 2.2, we have the additional requirements of limited scope of change to implementations - we didn't define what that meant precisely (and that is a good thing), but there is a strong argument that limited scope of change would require at least a majority of implementations to agree that the change is minor. Bill On May 27, 2009, at 12:48 PM, Erez Haba wrote: Hi all, I'm not really sure how to respond to this email. I will just note that this proposal has passed 1st vote last September with the following results. 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: YES: 17 NO: 4 ABSTAIN: 6 MISSED: 0 Result: Ballot passed http://meetings.mpi-forum.org/secretary/2008/09/votes.php ince then we decided to postpone the 1st vote to add very few minor correction to ticket #46 (the original proposal) and thus created ticket #140. I believe that all the points you mention below have been discussed in the forum meeting(s). Thanks, .Erez From: mpi-forum-bounces_at_[hidden] [mailto:mpi-forum-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Wednesday, May 27, 2009 6:53 AM To: Main MPI Forum mailing list Cc: mpi-22_at_[hidden] Subject: [Mpi-forum] The const proposal - Ticket 140 All - The signatories of this letter represent the majority of MPI implementors participating in the MPI Forum. We are concerned that proposal #140 ("Add const Keyword to the C bindings") has a number of issues which suggest delaying to MPI-3 would be appropriate. In particular, the proposal: - Is likely to pass a simple majority vote, but does not carry the support of the majority of MPI implementors, suggesting consensus has not been reached. - Changes 90+ MPI API interfaces, which is not a "trivial" change and therefore does not meet the intent of the MPI-2.2 process. - Is not needed to fix any serious bug in the standard text or to solve an issue that cannot easily be avoided by the MPI application. - Does not offer any demonstrable optimization opportunities for implementation or application, but may constrain future implementation opportunities. Therefore, we ask for your assistance in deferring proposal #140 to the MPI-3 process, where more time can be spent assessing its impact. Thank you, - Cisco: Jeff Squires - Intel: Alexander Supalov & Keith Underwood - Sandia: Brian Barrett - IBM: Richard Treumann - QLogic: Avneesh Pant - UTenn: George Bosilca - HP: David George Solt - UHouston: Edgar Gabriel - Myricom: Patrick Geoffray - ORNL: Richard Graham - Sun: Terry Dontje - NEC: Hubert Ritzdorf & Jesper Traeff Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronis at [hidden] Mon Jun 1 17:28:29 2009 From: bronis at [hidden] (Bronis R. de Supinski) Date: Mon, 1 Jun 2009 15:28:29 -0700 (PDT) Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: <6B68D01C00C9994A8E150183E62A119E855F27321F@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: Erez: Please do not simply withdraw it. There are a substantial portion of us who you convinced this was a good idea and what I saw in the feedback was that some found that it was outside the scope of 2.2. I think some of those people still feel it is a good idea even if that is the case. I hope you will press for 3.0. Bronis On Mon, 1 Jun 2009, Erez Haba wrote: > With this feedback of my distinguish colleagues, I don't see any point of perusing this proposal and I will be withdrawing this ticket in the next mpi forum meeting. > > Thanks, > .Erez > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp > Sent: Wednesday, May 27, 2009 11:37 AM > To: MPI 2.2 > Cc: Main MPI Forum mailing list > Subject: Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 > > This is an example of why we have two votes - to give everyone a chance to take a second look at the issues. I'll note that the 17-10 (counting no's and abstains together) is worrisome; while a majority vote is the rule, a good standard will make a compelling argument for each feature. > > The process here would normally be to have a debate and then the second vote. However, for MPI 2.2, we have the additional requirements of limited scope of change to implementations - we didn't define what that meant precisely (and that is a good thing), but there is a strong argument that limited scope of change would require at least a majority of implementations to agree that the change is minor. > > Bill > > On May 27, 2009, at 12:48 PM, Erez Haba wrote: > > > Hi all, I'm not really sure how to respond to this email. I will just note that this proposal has passed 1st vote last September with the following results. > > 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: > YES: > > 17 > > NO: > > 4 > > ABSTAIN: > > 6 > > MISSED: > > 0 > > Result: > > Ballot passed > > > http://meetings.mpi-forum.org/secretary/2008/09/votes.php > > since then we decided to postpone the 1st vote to add very few minor correction to ticket #46 (the original proposal) and thus created ticket #140. > > I believe that all the points you mention below have been discussed in the forum meeting(s). > > Thanks, > .Erez > > From: mpi-forum-bounces_at_[hidden] [mailto:mpi-forum-bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Wednesday, May 27, 2009 6:53 AM > To: Main MPI Forum mailing list > Cc: mpi-22_at_[hidden] > Subject: [Mpi-forum] The const proposal - Ticket 140 > > > All - > > The signatories of this letter represent the majority of MPI implementors participating in the MPI Forum. We are concerned that proposal #140 ("Add const Keyword to the C bindings") has a number of issues which suggest delaying to MPI-3 would be appropriate. > > In particular, the proposal: > > - Is likely to pass a simple majority vote, but does not carry the support of the majority of MPI implementors, suggesting consensus has not been reached. > - Changes 90+ MPI API interfaces, which is not a "trivial" change and therefore does not meet the intent of the MPI-2.2 process. > - Is not needed to fix any serious bug in the standard text or to solve an issue that cannot easily be avoided by the MPI application. > - Does not offer any demonstrable optimization opportunities for implementation or application, but may constrain future implementation opportunities. > > Therefore, we ask for your assistance in deferring proposal #140 to the MPI-3 process, where more time can be spent assessing its impact. > > Thank you, > > - Cisco: Jeff Squires > - Intel: Alexander Supalov & Keith Underwood > - Sandia: Brian Barrett > - IBM: Richard Treumann > - QLogic: Avneesh Pant > - UTenn: George Bosilca > - HP: David George Solt > - UHouston: Edgar Gabriel > - Myricom: Patrick Geoffray > - ORNL: Richard Graham > - Sun: Terry Dontje > - NEC: Hubert Ritzdorf & Jesper Traeff > > > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > > From treumann at [hidden] Tue Jun 2 09:36:47 2009 From: treumann at [hidden] (Richard Treumann) Date: Tue, 2 Jun 2009 10:36:47 -0400 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: Message-ID: Hi Bronis To the best of my knowledge, none of the signatories involved in asking that Ticket 140 not become part of MPI 2.2 consider it inappropriate for consideration in MPI 3.0 This proposal generated real interest among Forum members and I see no reason for it to be withdrawn entirely. Thank you Erez for agreeing to defer this to 3.0. It is a relief to a number of MPI implementors that if (or when) this becomes part of the MPI standard, we will have the lead time to do it properly and test it rigorously. Dick Treumann Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-forum-bounces_at_[hidden] wrote on 06/01/2009 06:28:29 PM: > [image removed] > > Re: [Mpi-forum] [Mpi-22] The const proposal - Ticket 140 > > Bronis R. de Supinski > > to: > > Main MPI Forum mailing list > > 06/01/2009 06:32 PM > > Sent by: > > mpi-forum-bounces_at_[hidden] > > Cc: > > "MPI 2.2" > > Please respond to "Bronis R. de Supinski", Main MPI Forum mailing list > > > Erez: > > Please do not simply withdraw it. There are a substantial > portion of us who you convinced this was a good idea and > what I saw in the feedback was that some found that it > was outside the scope of 2.2. I think some of those people > still feel it is a good idea even if that is the case. > I hope you will press for 3.0. > > Bronis > > > On Mon, 1 Jun 2009, Erez Haba wrote: > > > With this feedback of my distinguish colleagues, I don't see any > point of perusing this proposal and I will be withdrawing this > ticket in the next mpi forum meeting. > > > > Thanks, > > .Erez > > > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of William Gropp > > Sent: Wednesday, May 27, 2009 11:37 AM > > To: MPI 2.2 > > Cc: Main MPI Forum mailing list > > Subject: Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 > > > > This is an example of why we have two votes - to give everyone a > chance to take a second look at the issues. I'll note that the > 17-10 (counting no's and abstains together) is worrisome; while a > majority vote is the rule, a good standard will make a compelling > argument for each feature. > > > > The process here would normally be to have a debate and then the > second vote. However, for MPI 2.2, we have the additional > requirements of limited scope of change to implementations - we > didn't define what that meant precisely (and that is a good thing), > but there is a strong argument that limited scope of change would > require at least a majority of implementations to agree that the > change is minor. > > > > Bill > > > > On May 27, 2009, at 12:48 PM, Erez Haba wrote: > > > > > > Hi all, I'm not really sure how to respond to this email. I will > just note that this proposal has passed 1st vote last September with > the following results. > > > > 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: > > YES: > > > > 17 > > > > NO: > > > > 4 > > > > ABSTAIN: > > > > 6 > > > > MISSED: > > > > 0 > > > > Result: > > > > Ballot passed > > > > > > http://meetings.mpi-forum.org/secretary/2008/09/votes.php > > > > since then we decided to postpone the 1st vote to add very few > minor correction to ticket #46 (the original proposal) and thus > created ticket #140. > > > > I believe that all the points you mention below have been > discussed in the forum meeting(s). > > > > Thanks, > > .Erez > > > > From: mpi-forum-bounces_at_[hidden] bounces_at_[hidden]> [mailto:mpi-forum-bounces_at_[hidden] > ] On Behalf Of Richard Treumann > > Sent: Wednesday, May 27, 2009 6:53 AM > > To: Main MPI Forum mailing list > > Cc: mpi-22_at_[hidden] > > Subject: [Mpi-forum] The const proposal - Ticket 140 > > > > > > All - > > > > The signatories of this letter represent the majority of MPI > implementors participating in the MPI Forum. We are concerned that > proposal #140 ("Add const Keyword to the C bindings") has a number > of issues which suggest delaying to MPI-3 would be appropriate. > > > > In particular, the proposal: > > > > - Is likely to pass a simple majority vote, but does not carry the > support of the majority of MPI implementors, suggesting consensus > has not been reached. > > - Changes 90+ MPI API interfaces, which is not a "trivial" change > and therefore does not meet the intent of the MPI-2.2 process. > > - Is not needed to fix any serious bug in the standard text or to > solve an issue that cannot easily be avoided by the MPI application. > > - Does not offer any demonstrable optimization opportunities for > implementation or application, but may constrain future > implementation opportunities. > > > > Therefore, we ask for your assistance in deferring proposal #140 > to the MPI-3 process, where more time can be spent assessing its impact. > > > > Thank you, > > > > - Cisco: Jeff Squires > > - Intel: Alexander Supalov & Keith Underwood > > - Sandia: Brian Barrett > > - IBM: Richard Treumann > > - QLogic: Avneesh Pant > > - UTenn: George Bosilca > > - HP: David George Solt > > - UHouston: Edgar Gabriel > > - Myricom: Patrick Geoffray > > - ORNL: Richard Graham > > - Sun: Terry Dontje > > - NEC: Hubert Ritzdorf & Jesper Traeff > > > > > > > > Dick Treumann - MPI Team > > IBM Systems & Technology Group > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > William Gropp > > Deputy Director for Research > > Institute for Advanced Computing Applications and Technologies > > Paul and Cynthia Saylor Professor of Computer Science > > University of Illinois Urbana-Champaign > > > > > > > > > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum * -------------- next part -------------- An HTML attachment was scrubbed... URL: From balaji at [hidden] Fri Jun 5 08:21:12 2009 From: balaji at [hidden] (Pavan Balaji) Date: Fri, 05 Jun 2009 08:21:12 -0500 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: Message-ID: <4A291BC8.7030102@mcs.anl.gov> If this is being moved to MPI-3, we should consider modifying the ticket to include functions we left behind for backward compatibility. For example: int MPI_Comm_spawn(const char*, /*const*/char*[], int, MPI_Info, int, MPI_Comm, MPI_Comm*, int []); int MPI_Comm_spawn_multiple(int, /*const*/char*[], /*const*/char**[], const int [],/*const*/MPI_Info [], int, MPI_Comm, MPI_Comm*, int []); -- Pavan On 06/02/2009 09:36 AM, Richard Treumann wrote: > Hi Bronis > > To the best of my knowledge, none of the signatories involved in asking > that Ticket 140 not become part of MPI 2.2 consider it inappropriate for > consideration in MPI 3.0 > > This proposal generated real interest among Forum members and I see no > reason for it to be withdrawn entirely. > > Thank you Erez for agreeing to defer this to 3.0. It is a relief to a > number of MPI implementors that if (or when) this becomes part of the > MPI standard, we will have the lead time to do it properly and test it > rigorously. > > Dick Treumann > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-forum-bounces_at_[hidden] wrote on 06/01/2009 06:28:29 PM: > > > [image removed] > > > > Re: [Mpi-forum] [Mpi-22] The const proposal - Ticket 140 > > > > Bronis R. de Supinski > > > > to: > > > > Main MPI Forum mailing list > > > > 06/01/2009 06:32 PM > > > > Sent by: > > > > mpi-forum-bounces_at_[hidden] > > > > Cc: > > > > "MPI 2.2" > > > > Please respond to "Bronis R. de Supinski", Main MPI Forum mailing list > > > > > > Erez: > > > > Please do not simply withdraw it. There are a substantial > > portion of us who you convinced this was a good idea and > > what I saw in the feedback was that some found that it > > was outside the scope of 2.2. I think some of those people > > still feel it is a good idea even if that is the case. > > I hope you will press for 3.0. > > > > Bronis > > > > > > On Mon, 1 Jun 2009, Erez Haba wrote: > > > > > With this feedback of my distinguish colleagues, I don't see any > > point of perusing this proposal and I will be withdrawing this > > ticket in the next mpi forum meeting. > > > > > > Thanks, > > > .Erez > > > > > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > > bounces_at_[hidden]] On Behalf Of William Gropp > > > Sent: Wednesday, May 27, 2009 11:37 AM > > > To: MPI 2.2 > > > Cc: Main MPI Forum mailing list > > > Subject: Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 > > > > > > This is an example of why we have two votes - to give everyone a > > chance to take a second look at the issues. I'll note that the > > 17-10 (counting no's and abstains together) is worrisome; while a > > majority vote is the rule, a good standard will make a compelling > > argument for each feature. > > > > > > The process here would normally be to have a debate and then the > > second vote. However, for MPI 2.2, we have the additional > > requirements of limited scope of change to implementations - we > > didn't define what that meant precisely (and that is a good thing), > > but there is a strong argument that limited scope of change would > > require at least a majority of implementations to agree that the > > change is minor. > > > > > > Bill > > > > > > On May 27, 2009, at 12:48 PM, Erez Haba wrote: > > > > > > > > > Hi all, I'm not really sure how to respond to this email. I will > > just note that this proposal has passed 1st vote last September with > > the following results. > > > > > > 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: > > > YES: > > > > > > 17 > > > > > > NO: > > > > > > 4 > > > > > > ABSTAIN: > > > > > > 6 > > > > > > MISSED: > > > > > > 0 > > > > > > Result: > > > > > > Ballot passed > > > > > > > > > http://meetings.mpi-forum.org/secretary/2008/09/votes.php > > > > > > since then we decided to postpone the 1st vote to add very few > > minor correction to ticket #46 (the original proposal) and thus > > created ticket #140. > > > > > > I believe that all the points you mention below have been > > discussed in the forum meeting(s). > > > > > > Thanks, > > > .Erez > > > > > > From: mpi-forum-bounces_at_[hidden] > bounces_at_[hidden]> > [mailto:mpi-forum-bounces_at_[hidden] > > ] On Behalf Of Richard Treumann > > > Sent: Wednesday, May 27, 2009 6:53 AM > > > To: Main MPI Forum mailing list > > > Cc: mpi-22_at_[hidden] > > > Subject: [Mpi-forum] The const proposal - Ticket 140 > > > > > > > > > All - > > > > > > The signatories of this letter represent the majority of MPI > > implementors participating in the MPI Forum. We are concerned that > > proposal #140 ("Add const Keyword to the C bindings") has a number > > of issues which suggest delaying to MPI-3 would be appropriate. > > > > > > In particular, the proposal: > > > > > > - Is likely to pass a simple majority vote, but does not carry the > > support of the majority of MPI implementors, suggesting consensus > > has not been reached. > > > - Changes 90+ MPI API interfaces, which is not a "trivial" change > > and therefore does not meet the intent of the MPI-2.2 process. > > > - Is not needed to fix any serious bug in the standard text or to > > solve an issue that cannot easily be avoided by the MPI application. > > > - Does not offer any demonstrable optimization opportunities for > > implementation or application, but may constrain future > > implementation opportunities. > > > > > > Therefore, we ask for your assistance in deferring proposal #140 > > to the MPI-3 process, where more time can be spent assessing its impact. > > > > > > Thank you, > > > > > > - Cisco: Jeff Squires > > > - Intel: Alexander Supalov & Keith Underwood > > > - Sandia: Brian Barrett > > > - IBM: Richard Treumann > > > - QLogic: Avneesh Pant > > > - UTenn: George Bosilca > > > - HP: David George Solt > > > - UHouston: Edgar Gabriel > > > - Myricom: Patrick Geoffray > > > - ORNL: Richard Graham > > > - Sun: Terry Dontje > > > - NEC: Hubert Ritzdorf & Jesper Traeff > > > > > > > > > > > > Dick Treumann - MPI Team > > > IBM Systems & Technology Group > > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > > > > William Gropp > > > Deputy Director for Research > > > Institute for Advanced Computing Applications and Technologies > > > Paul and Cynthia Saylor Professor of Computer Science > > > University of Illinois Urbana-Champaign > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > ------------------------------------------------------------------------ > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Pavan Balaji http://www.mcs.anl.gov/~balaji From thakur at [hidden] Fri Jun 5 08:54:27 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 5 Jun 2009 08:54:27 -0500 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: <4A291BC8.7030102@mcs.anl.gov> Message-ID: <191C19A6D9AC479AB2A380FB7A0B8E96@thakurlaptop> And it should include the new nonblocking collectives... Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Pavan Balaji > Sent: Friday, June 05, 2009 8:21 AM > To: MPI 2.2 > Cc: Main MPI Forum mailing list > Subject: Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 > > > If this is being moved to MPI-3, we should consider modifying > the ticket to include functions we left behind for backward > compatibility. For example: > > int MPI_Comm_spawn(const char*, /*const*/char*[], int, > MPI_Info, int, MPI_Comm, MPI_Comm*, int []); > > int MPI_Comm_spawn_multiple(int, /*const*/char*[], > /*const*/char**[], const int [],/*const*/MPI_Info [], int, > MPI_Comm, MPI_Comm*, int []); > > -- Pavan > > On 06/02/2009 09:36 AM, Richard Treumann wrote: > > Hi Bronis > > > > To the best of my knowledge, none of the signatories involved in > > asking that Ticket 140 not become part of MPI 2.2 consider it > > inappropriate for consideration in MPI 3.0 > > > > This proposal generated real interest among Forum members > and I see no > > reason for it to be withdrawn entirely. > > > > Thank you Erez for agreeing to defer this to 3.0. It is a > relief to a > > number of MPI implementors that if (or when) this becomes > part of the > > MPI standard, we will have the lead time to do it properly > and test it > > rigorously. > > > > Dick Treumann > > > > Dick Treumann - MPI Team > > IBM Systems & Technology Group > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY > 12601 Tele > > (845) 433-7846 Fax (845) 433-8363 > > > > > > mpi-forum-bounces_at_[hidden] wrote on 06/01/2009 > 06:28:29 PM: > > > > > [image removed] > > > > > > Re: [Mpi-forum] [Mpi-22] The const proposal - Ticket 140 > > > > Bronis R. de Supinski > > to: > > > > > > Main MPI Forum mailing list > > > > > > 06/01/2009 06:32 PM > > > > > > Sent by: > > > > > > mpi-forum-bounces_at_[hidden] > > > > > > Cc: > > > > > > "MPI 2.2" > > > > > > Please respond to "Bronis R. de Supinski", Main MPI > Forum mailing > > list > > > Erez: > > > > > > Please do not simply withdraw it. There are a substantial > > > portion of us who you convinced this was a good idea and > > what I saw > > in the feedback was that some found that it > was outside > the scope > > of 2.2. I think some of those people > still feel it is a > good idea > > even if that is the case. > > > I hope you will press for 3.0. > > > > > > Bronis > > > > > > > > > On Mon, 1 Jun 2009, Erez Haba wrote: > > > > > > > With this feedback of my distinguish colleagues, I > don't see any > > > point of perusing this proposal and I will be withdrawing this > > > ticket in the next mpi forum meeting. > > > > > > > > Thanks, > > > > .Erez > > > > > > > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > > > bounces_at_[hidden]] On Behalf Of William Gropp > > Sent: > > Wednesday, May 27, 2009 11:37 AM > > To: MPI 2.2 > > Cc: Main MPI > > Forum mailing list > > Subject: Re: [Mpi-22] [Mpi-forum] The const > > proposal - Ticket 140 > > > > This is an example of why > we have two > > votes - to give everyone a > chance to take a second look at the > > issues. I'll note that the > 17-10 (counting no's and abstains > > together) is worrisome; while a > majority vote is the > rule, a good > > standard will make a compelling > argument for each feature. > > > > > > > > The process here would normally be to have a debate > and then the > > > second vote. However, for MPI 2.2, we have the additional > > > requirements of limited scope of change to implementations - we > > > didn't define what that meant precisely (and that is a good > thing), > > > but there is a strong argument that limited scope of change > would > > > require at least a majority of implementations to agree that the > > > change is minor. > > > > > > > > Bill > > > > > > > > On May 27, 2009, at 12:48 PM, Erez Haba wrote: > > > > > > > > > > > > Hi all, I'm not really sure how to respond to this > email. I will > > > just note that this proposal has passed 1st vote last > September with > > > the following results. > > > > > > > > 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: > > > > YES: > > > > > > > > 17 > > > > > > > > NO: > > > > > > > > 4 > > > > > > > > ABSTAIN: > > > > > > > > 6 > > > > > > > > MISSED: > > > > > > > > 0 > > > > > > > > Result: > > > > > > > > Ballot passed > > > > > > > > > > > > http://meetings.mpi-forum.org/secretary/2008/09/votes.php > > > > > > > > since then we decided to postpone the 1st vote to add > very few > > > minor correction to ticket #46 (the original proposal) and thus > > > created ticket #140. > > > > > > > > I believe that all the points you mention below have been > > > discussed in the forum meeting(s). > > > > > > > > Thanks, > > > > .Erez > > > > > > > > From: mpi-forum-bounces_at_[hidden] > > bounces_at_[hidden]> > > [mailto:mpi-forum-bounces_at_[hidden] > > > ] On Behalf Of Richard Treumann > > > > Sent: Wednesday, May 27, 2009 6:53 AM > > To: Main MPI Forum > > mailing list > > Cc: > > mpi-22_at_[hidden] > > > > Subject: [Mpi-forum] The const proposal - Ticket 140 > > > > > > > > > All - > > > > The signatories of this letter represent the > > majority of MPI > implementors participating in the MPI > Forum. We are > > concerned that > proposal #140 ("Add const Keyword to the C > > bindings") has a number > of issues which suggest delaying > to MPI-3 > > would be appropriate. > > > > > > > > In particular, the proposal: > > > > > > > > - Is likely to pass a simple majority vote, but does not carry > > the > support of the majority of MPI implementors, suggesting > > consensus > has not been reached. > > > > - Changes 90+ MPI API interfaces, which is not a > "trivial" change > > > and therefore does not meet the intent of the MPI-2.2 process. > > > > - Is not needed to fix any serious bug in the standard > text or to > > > solve an issue that cannot easily be avoided by the MPI > application. > > > > - Does not offer any demonstrable optimization > opportunities for > > > implementation or application, but may constrain future > > > implementation opportunities. > > > > > > > > Therefore, we ask for your assistance in deferring > proposal #140 > > > to the MPI-3 process, where more time can be spent > assessing its impact. > > > > > > > > Thank you, > > > > > > > > - Cisco: Jeff Squires > > > > - Intel: Alexander Supalov & Keith Underwood > > - > Sandia: Brian > > Barrett > > - IBM: Richard Treumann > > - QLogic: Avneesh > Pant > > > > - UTenn: George Bosilca > > - HP: David George Solt > > - > UHouston: > > Edgar Gabriel > > - Myricom: Patrick Geoffray > > - ORNL: Richard > > Graham > > - Sun: Terry Dontje > > - NEC: Hubert Ritzdorf > & Jesper > > Traeff > > > > > > > > Dick Treumann - MPI Team > > > IBM Systems & > > Technology Group > > Dept X2ZA / MS P963 -- 2455 South Road -- > > Poughkeepsie, NY 12601 > > Tele (845) 433-7846 Fax (845) > 433-8363 > > > > > > > > William Gropp > > Deputy Director for > > Research > > Institute for Advanced Computing Applications and > > Technologies > > Paul and Cynthia Saylor Professor of Computer > > Science > > University of Illinois Urbana-Champaign > > > > > > > > > > > > > > > > _______________________________________________ > > > mpi-forum mailing list > > > mpi-forum_at_[hidden] > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > From traff at [hidden] Mon Jun 8 09:43:45 2009 From: traff at [hidden] (Jesper-Larsson Träff) Date: Mon, 8 Jun 2009 16:43:45 +0200 Subject: [Mpi-22] [MPI Forum] #37: Clarify semantics of one-sided semantics when changing synchronization mode In-Reply-To: <052.63a32525867c37c2d7a940ed7154fcfd@lists.mpi-forum.org> Message-ID: <20090608144345.GB13269@fourier.it.neclab.eu> Thanks a lot, Rolf! Jesper On Mon, Jun 08, 2009 at 02:19:10PM -0000, MPI Forum wrote: > #37: Clarify semantics of one-sided semantics when changing synchronization mode > -----------------------------------+---------------------------------------- > Reporter: traff | Owner: traff > Type: Correction to standard | Status: new > Priority: Had 1st reading | Milestone: 2009/06/08 California > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Unnecessary > -----------------------------------+---------------------------------------- > > Comment(by RolfRabenseifner): > > I checked the discussion and all modifications since my last review: > - All late reviews are implemented. > - All modifications in the ticket's description are helpful and correct. > - Especially the the removal of the last paragraph. > - I agree that the modifications are minor and therefore, the status > should be kept on "Had 1st reading". > > -- > Ticket URL: > MPI Forum > MPI Forum * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4642 bytes Desc: smime.p7s URL: From jsquyres at [hidden] Thu Jun 11 07:37:26 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 11 Jun 2009 05:37:26 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex Message-ID: <34900C88-B0BF-4ABE-9908-4F83582A3C0A@cisco.com> Torsten raised an excellent point in Menlo Park: we need to amend our 2.2 ticket process to include appropriate checks after a proposal has passed to ensure that the resulting text is committed properly and without errors. As discussed in Menlo Park, the suggestion is that chapter authors commit the text to SVN and then attach a PDF to the ticket to get reviewed by the existing ticket reviewers (potentially just a few PDF pages showing the changes). Reviewers check that the resulting PDF is exactly what was passed in the body of the proposal. Once the PDF passes review, the ticket can be closed. --> Rolf/Bill: chapter authors will need guidance on the appropriate Latex markup for signifying changes for MPI-2.2 (e.g., the text- coloring magic). A picture is worth 1,000 words: I have attached a suggested diagram of Trac ticket state transitions -- the new states are yellow and underlined (some old states changed names slightly; those changed are yellow/underlined as well). Comments? (particularly from Bill and chapter authors) -- Jeff Squyres Cisco Systems * -------------- next part -------------- A non-text attachment was scrubbed... Name: MPI-2.2_ticket_states-suggested.pdf Type: application/pdf Size: 481354 bytes Desc: MPI-2.2_ticket_states-suggested.pdf URL: From wgropp at [hidden] Thu Jun 11 09:00:47 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 11 Jun 2009 09:00:47 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <34900C88-B0BF-4ABE-9908-4F83582A3C0A@cisco.com> Message-ID: Thanks, Jeff and Torsten. I was about to ask for new states on the tickets for just this purpose. I've also updated the README-2.2 to provide documentation on the markup to be used for 2.2 updates; I'm currently testing and refining the definition of those macros. I'm trying those out on my chapters, plus ticket 16 from the datatypes chapter. Bill On Jun 11, 2009, at 7:37 AM, Jeff Squyres wrote: > Torsten raised an excellent point in Menlo Park: we need to amend our > 2.2 ticket process to include appropriate checks after a proposal has > passed to ensure that the resulting text is committed properly and > without errors. > > As discussed in Menlo Park, the suggestion is that chapter authors > commit the text to SVN and then attach a PDF to the ticket to get > reviewed by the existing ticket reviewers (potentially just a few PDF > pages showing the changes). Reviewers check that the resulting PDF is > exactly what was passed in the body of the proposal. Once the PDF > passes review, the ticket can be closed. > > --> Rolf/Bill: chapter authors will need guidance on the appropriate > Latex markup for signifying changes for MPI-2.2 (e.g., the text- > coloring magic). > > A picture is worth 1,000 words: I have attached a suggested diagram of > Trac ticket state transitions -- the new states are yellow and > underlined (some old states changed names slightly; those changed are > yellow/underlined as well). > > Comments? (particularly from Bill and chapter authors) > > -- > Jeff Squyres > Cisco Systems > William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Thu Jun 11 09:58:28 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 11 Jun 2009 07:58:28 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: On Jun 11, 2009, at 7:00 AM, William Gropp wrote: > Thanks, Jeff and Torsten. I was about to ask for new states on the > tickets for just this purpose. > To be clear -- I haven't added these states to trac yet. I wanted to make sure they were palatable to everyone first. Give me the "go" and I'll add them. > I've also updated the README-2.2 to > provide documentation on the markup to be used for 2.2 updates; I'm > currently testing and refining the definition of those macros. I'm > trying those out on my chapters, plus ticket 16 from the datatypes > chapter. > > Bill > > On Jun 11, 2009, at 7:37 AM, Jeff Squyres wrote: > > > Torsten raised an excellent point in Menlo Park: we need to amend > our > > 2.2 ticket process to include appropriate checks after a proposal > has > > passed to ensure that the resulting text is committed properly and > > without errors. > > > > As discussed in Menlo Park, the suggestion is that chapter authors > > commit the text to SVN and then attach a PDF to the ticket to get > > reviewed by the existing ticket reviewers (potentially just a few > PDF > > pages showing the changes). Reviewers check that the resulting > PDF is > > exactly what was passed in the body of the proposal. Once the PDF > > passes review, the ticket can be closed. > > > > --> Rolf/Bill: chapter authors will need guidance on the appropriate > > Latex markup for signifying changes for MPI-2.2 (e.g., the text- > > coloring magic). > > > > A picture is worth 1,000 words: I have attached a suggested > diagram of > > Trac ticket state transitions -- the new states are yellow and > > underlined (some old states changed names slightly; those changed > are > > yellow/underlined as well). > > > > Comments? (particularly from Bill and chapter authors) > > > > -- > > Jeff Squyres > > Cisco Systems > > > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From wgropp at [hidden] Thu Jun 11 10:16:06 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 11 Jun 2009 10:16:06 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <34900C88-B0BF-4ABE-9908-4F83582A3C0A@cisco.com> Message-ID: <2C51D003-B80A-47D5-9C41-41C39CA7D324@illinois.edu> Do we need separate "text committed" and "awaiting PDF reviews"? Why not just a "committed and PDF awaiting review"? Bill On Jun 11, 2009, at 7:37 AM, Jeff Squyres wrote: > Torsten raised an excellent point in Menlo Park: we need to amend our > 2.2 ticket process to include appropriate checks after a proposal has > passed to ensure that the resulting text is committed properly and > without errors. > > As discussed in Menlo Park, the suggestion is that chapter authors > commit the text to SVN and then attach a PDF to the ticket to get > reviewed by the existing ticket reviewers (potentially just a few PDF > pages showing the changes). Reviewers check that the resulting PDF is > exactly what was passed in the body of the proposal. Once the PDF > passes review, the ticket can be closed. > > --> Rolf/Bill: chapter authors will need guidance on the appropriate > Latex markup for signifying changes for MPI-2.2 (e.g., the text- > coloring magic). > > A picture is worth 1,000 words: I have attached a suggested diagram of > Trac ticket state transitions -- the new states are yellow and > underlined (some old states changed names slightly; those changed are > yellow/underlined as well). > > Comments? (particularly from Bill and chapter authors) > > -- > Jeff Squyres > Cisco Systems > William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Thu Jun 11 10:46:47 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 11 Jun 2009 08:46:47 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <2C51D003-B80A-47D5-9C41-41C39CA7D324@illinois.edu> Message-ID: <8618C9E5-2FF0-4889-9DA1-29C199680A98@cisco.com> On Jun 11, 2009, at 8:16 AM, William Gropp wrote: > Do we need separate "text committed" and "awaiting PDF reviews"? Why > not just a "committed and PDF awaiting review"? > Having two states made sense to me when I drew the picture. But now I can't remember why. :-) I wanted a state to wait in while the reviewers are checking the [latest] PDF. I think you're right that we only need 1 state for that. See attached. -- Jeff Squyres Cisco Systems * -------------- next part -------------- A non-text attachment was scrubbed... Name: MPI-2.2_ticket_states.pdf Type: application/pdf Size: 457853 bytes Desc: MPI-2.2_ticket_states.pdf URL: From thakur at [hidden] Thu Jun 11 11:21:24 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Thu, 11 Jun 2009 11:21:24 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <34900C88-B0BF-4ABE-9908-4F83582A3C0A@cisco.com> Message-ID: One question is how do chapter authors know which of the 80+ tickets for 2.2 apply to their chapter? And some apply to multiple chapters. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, June 11, 2009 7:37 AM > To: MPI 2.2 > Subject: [Mpi-22] SVN committing MPI-2.2 latex > > Torsten raised an excellent point in Menlo Park: we need to > amend our > 2.2 ticket process to include appropriate checks after a > proposal has > passed to ensure that the resulting text is committed properly and > without errors. > > As discussed in Menlo Park, the suggestion is that chapter authors > commit the text to SVN and then attach a PDF to the ticket to get > reviewed by the existing ticket reviewers (potentially just a > few PDF > pages showing the changes). Reviewers check that the > resulting PDF is > exactly what was passed in the body of the proposal. Once the PDF > passes review, the ticket can be closed. > > --> Rolf/Bill: chapter authors will need guidance on the appropriate > Latex markup for signifying changes for MPI-2.2 (e.g., the text- > coloring magic). > > A picture is worth 1,000 words: I have attached a suggested > diagram of > Trac ticket state transitions -- the new states are yellow and > underlined (some old states changed names slightly; those > changed are > yellow/underlined as well). > > Comments? (particularly from Bill and chapter authors) > > -- > Jeff Squyres > Cisco Systems > From wgropp at [hidden] Thu Jun 11 11:24:17 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 11 Jun 2009 11:24:17 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: <43D819A0-F78C-4C4E-9E12-24B87EC74CCF@illinois.edu> I've put together a spreadsheet, so I know who they are - and I will let them know. Bill On Jun 11, 2009, at 11:21 AM, Rajeev Thakur wrote: > One question is how do chapter authors know which of the 80+ tickets > for > 2.2 apply to their chapter? And some apply to multiple chapters. > > Rajeev > >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres >> Sent: Thursday, June 11, 2009 7:37 AM >> To: MPI 2.2 >> Subject: [Mpi-22] SVN committing MPI-2.2 latex >> >> Torsten raised an excellent point in Menlo Park: we need to >> amend our >> 2.2 ticket process to include appropriate checks after a >> proposal has >> passed to ensure that the resulting text is committed properly and >> without errors. >> >> As discussed in Menlo Park, the suggestion is that chapter authors >> commit the text to SVN and then attach a PDF to the ticket to get >> reviewed by the existing ticket reviewers (potentially just a >> few PDF >> pages showing the changes). Reviewers check that the >> resulting PDF is >> exactly what was passed in the body of the proposal. Once the PDF >> passes review, the ticket can be closed. >> >> --> Rolf/Bill: chapter authors will need guidance on the appropriate >> Latex markup for signifying changes for MPI-2.2 (e.g., the text- >> coloring magic). >> >> A picture is worth 1,000 words: I have attached a suggested >> diagram of >> Trac ticket state transitions -- the new states are yellow and >> underlined (some old states changed names slightly; those >> changed are >> yellow/underlined as well). >> >> Comments? (particularly from Bill and chapter authors) >> >> -- >> Jeff Squyres >> Cisco Systems >> > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Thu Jun 11 11:58:17 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 11 Jun 2009 09:58:17 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <43D819A0-F78C-4C4E-9E12-24B87EC74CCF@illinois.edu> Message-ID: <3B5DF41C-689F-40F2-9E88-18C14712A0A4@cisco.com> Do you want to add a field to the tickets with chapter author trac ID? On Jun 11, 2009, at 9:24 AM, William Gropp wrote: > I've put together a spreadsheet, so I know who they are - and I will > let them know. > > Bill > > On Jun 11, 2009, at 11:21 AM, Rajeev Thakur wrote: > > > One question is how do chapter authors know which of the 80+ tickets > > for > > 2.2 apply to their chapter? And some apply to multiple chapters. > > > > Rajeev > > > >> -----Original Message----- > >> From: mpi-22-bounces_at_[hidden] > >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > >> Sent: Thursday, June 11, 2009 7:37 AM > >> To: MPI 2.2 > >> Subject: [Mpi-22] SVN committing MPI-2.2 latex > >> > >> Torsten raised an excellent point in Menlo Park: we need to > >> amend our > >> 2.2 ticket process to include appropriate checks after a > >> proposal has > >> passed to ensure that the resulting text is committed properly and > >> without errors. > >> > >> As discussed in Menlo Park, the suggestion is that chapter authors > >> commit the text to SVN and then attach a PDF to the ticket to get > >> reviewed by the existing ticket reviewers (potentially just a > >> few PDF > >> pages showing the changes). Reviewers check that the > >> resulting PDF is > >> exactly what was passed in the body of the proposal. Once the PDF > >> passes review, the ticket can be closed. > >> > >> --> Rolf/Bill: chapter authors will need guidance on the > appropriate > >> Latex markup for signifying changes for MPI-2.2 (e.g., the text- > >> coloring magic). > >> > >> A picture is worth 1,000 words: I have attached a suggested > >> diagram of > >> Trac ticket state transitions -- the new states are yellow and > >> underlined (some old states changed names slightly; those > >> changed are > >> yellow/underlined as well). > >> > >> Comments? (particularly from Bill and chapter authors) > >> > >> -- > >> Jeff Squyres > >> Cisco Systems > >> > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From thakur at [hidden] Thu Jun 11 12:53:49 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Thu, 11 Jun 2009 12:53:49 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <3B5DF41C-689F-40F2-9E88-18C14712A0A4@cisco.com> Message-ID: <2D264FEF697F4C0CAB4D40955B7C691C@mcs.anl.gov> That would be good as chapter authors can search for which tickets they need to incorporate. > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, June 11, 2009 11:58 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] SVN committing MPI-2.2 latex > > Do you want to add a field to the tickets with chapter author trac ID? > > > On Jun 11, 2009, at 9:24 AM, William Gropp wrote: > > > I've put together a spreadsheet, so I know who they are - and I will > > let them know. > > > > Bill > > > > On Jun 11, 2009, at 11:21 AM, Rajeev Thakur wrote: > > > > > One question is how do chapter authors know which of the > 80+ tickets > > > for > > > 2.2 apply to their chapter? And some apply to multiple chapters. > > > > > > Rajeev > > > > > >> -----Original Message----- > > >> From: mpi-22-bounces_at_[hidden] > > >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff > > Squyres > > >> Sent: Thursday, June 11, 2009 7:37 AM > > >> To: MPI 2.2 > > >> Subject: [Mpi-22] SVN committing MPI-2.2 latex > > >> > > >> Torsten raised an excellent point in Menlo Park: we need to > > >> amend our > > >> 2.2 ticket process to include appropriate checks after a > > >> proposal has > > >> passed to ensure that the resulting text is committed > properly and > > >> without errors. > > >> > > >> As discussed in Menlo Park, the suggestion is that > chapter authors > > >> commit the text to SVN and then attach a PDF to the ticket to get > > >> reviewed by the existing ticket reviewers (potentially just a > > >> few PDF > > >> pages showing the changes). Reviewers check that the > > >> resulting PDF is > > >> exactly what was passed in the body of the proposal. > Once the PDF > > >> passes review, the ticket can be closed. > > >> > > >> --> Rolf/Bill: chapter authors will need guidance on the > > appropriate > > >> Latex markup for signifying changes for MPI-2.2 (e.g., the text- > > >> coloring magic). > > >> > > >> A picture is worth 1,000 words: I have attached a suggested > > >> diagram of > > >> Trac ticket state transitions -- the new states are yellow and > > >> underlined (some old states changed names slightly; those > > >> changed are > > >> yellow/underlined as well). > > >> > > >> Comments? (particularly from Bill and chapter authors) > > >> > > >> -- > > >> Jeff Squyres > > >> Cisco Systems > > >> > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > William Gropp > > Deputy Director for Research > > Institute for Advanced Computing Applications and Technologies > > Paul and Cynthia Saylor Professor of Computer Science > > University of Illinois Urbana-Champaign > > > > > > > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > From rabenseifner at [hidden] Thu Jun 11 13:20:24 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 11 Jun 2009 20:20:24 +0200 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <8618C9E5-2FF0-4889-9DA1-29C199680A98@cisco.com> Message-ID: Jeff, As far as I understand, tickets are implemented by the chapter-authors and not by the ticket-authors? In your state diagram, you may differentiate between ticket author and chapter author. Please can you use a new color for the chapter-author trasitions. If a reviewer detects a bug, he should set the state back to "Passed". A new color for the reviewer is also needed for this transition. Most tickets have at least two chapter authors: - the main chapter author - and me, the author of the Change-Log. I plan to do all Change-Log entries of all passed tickets - in a few days - and after next meeting. Then the chapter authors can use in their sniplets also the appropriate change-log page. Best regards Rolf On Thu, 11 Jun 2009 08:46:47 -0700 Jeff Squyres wrote: > On Jun 11, 2009, at 8:16 AM, William Gropp wrote: > >> Do we need separate "text committed" and "awaiting PDF reviews"? >> Why >> not just a "committed and PDF awaiting review"? >> > > Having two states made sense to me when I drew the picture. But now >I can't remember why. :-) > > I wanted a state to wait in while the reviewers are checking the > [latest] PDF. I think you're right that we only need 1 state for > that. See attached. > > -- > Jeff Squyres > Cisco Systems Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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) From wgropp at [hidden] Fri Jun 12 03:49:48 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 12 Jun 2009 03:49:48 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <3B5DF41C-689F-40F2-9E88-18C14712A0A4@cisco.com> Message-ID: <040F61B1-0B59-45E9-8E0F-67887E3B7071@illinois.edu> Some tickets involve multiple chapters, not counting the change log (though most of the currently passed items will not have change log entries as they are clarifications to the text that do not impact implementations). It would be useful to have a field with a list of the authors, though I'd also need a mapping of email/Name to trac ID for this in order to fill this in (my list is by name). For the items that have multiple authors, the easiest way for the authors is provide PDFs for their sections (I've already done that for the tickets that overlap my chapters). Is there some easy way to associate these files with the authors when there are multiple chapter authors involved? Bill On Jun 11, 2009, at 11:58 AM, Jeff Squyres wrote: > Do you want to add a field to the tickets with chapter author trac ID? > > > On Jun 11, 2009, at 9:24 AM, William Gropp wrote: > >> I've put together a spreadsheet, so I know who they are - and I will >> let them know. >> >> Bill >> >> On Jun 11, 2009, at 11:21 AM, Rajeev Thakur wrote: >> >>> One question is how do chapter authors know which of the 80+ tickets >>> for >>> 2.2 apply to their chapter? And some apply to multiple chapters. >>> >>> Rajeev >>> >>>> -----Original Message----- >>>> From: mpi-22-bounces_at_[hidden] >>>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff >> Squyres >>>> Sent: Thursday, June 11, 2009 7:37 AM >>>> To: MPI 2.2 >>>> Subject: [Mpi-22] SVN committing MPI-2.2 latex >>>> >>>> Torsten raised an excellent point in Menlo Park: we need to >>>> amend our >>>> 2.2 ticket process to include appropriate checks after a >>>> proposal has >>>> passed to ensure that the resulting text is committed properly and >>>> without errors. >>>> >>>> As discussed in Menlo Park, the suggestion is that chapter authors >>>> commit the text to SVN and then attach a PDF to the ticket to get >>>> reviewed by the existing ticket reviewers (potentially just a >>>> few PDF >>>> pages showing the changes). Reviewers check that the >>>> resulting PDF is >>>> exactly what was passed in the body of the proposal. Once the PDF >>>> passes review, the ticket can be closed. >>>> >>>> --> Rolf/Bill: chapter authors will need guidance on the >> appropriate >>>> Latex markup for signifying changes for MPI-2.2 (e.g., the text- >>>> coloring magic). >>>> >>>> A picture is worth 1,000 words: I have attached a suggested >>>> diagram of >>>> Trac ticket state transitions -- the new states are yellow and >>>> underlined (some old states changed names slightly; those >>>> changed are >>>> yellow/underlined as well). >>>> >>>> Comments? (particularly from Bill and chapter authors) >>>> >>>> -- >>>> Jeff Squyres >>>> Cisco Systems >>>> >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Fri Jun 12 07:09:51 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Jun 2009 05:09:51 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: <1B2CC34D-C3A2-4C7C-AF15-9749DCDD5ED8@cisco.com> On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: > In your state diagram, you may differentiate between ticket author > and chapter author. Please can you use a new color for the chapter- > author trasitions. > Can do. > If a reviewer detects a bug, he should set the state back to > "Passed". A new color for the reviewer is also needed for this > transition. > I think that this is what I was thinking when I had an extra state in my first diagram -- that the states would go between "text committed" and "waiting for PDF reviews" until it was finally "ticket complete". So do you want to make the reviewers responsible for changing the state back away from "waiting for PDF reviews" to the previous state? That would be different than what we did for proposals, where the proposal author or chair would move the ticket between "forum feedback requested", "not ready", and "waiting for (proposal) reviews". -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Fri Jun 12 07:33:36 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Jun 2009 05:33:36 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <040F61B1-0B59-45E9-8E0F-67887E3B7071@illinois.edu> Message-ID: <573673DA-B3E3-4DF1-B9C9-57B46FFC010C@cisco.com> On Jun 12, 2009, at 1:49 AM, William Gropp wrote: > Some tickets involve multiple chapters, not counting the change log > (though most of the currently passed items will not have change log > entries as they are clarifications to the text that do not impact > implementations). It would be useful to have a field with a list of > the authors, though I'd also need a mapping of email/Name to trac ID > for this in order to fill this in (my list is by name). > It looks like Trac will let me add this in one of two ways: 1. A text box where you can type in author names. 2. A series of checkboxes, one for each chapter author (e.g., "Jeff Squyres __, Bill Gropp ___, ...etc."). The advantage of #1 is simplicity. The advantage of #2 is commonality / ease of searching. Which would you prefer? > For the items that have multiple authors, the easiest way for the > authors is provide PDFs for their sections (I've already done that for > the tickets that overlap my chapters). Is there some easy way to > associate these files with the authors when there are multiple chapter > authors involved? > Probably not -- I think attachments are attachments. Perhaps we should just have a filename convention? chap-.pdf, like they are produced when you "make" in the chapter subdirectory? I'd also suggest that authors should snip and only include the relevant pages when possible (rather than the entire chapter) -- Jeff Squyres Cisco Systems From rabenseifner at [hidden] Fri Jun 12 07:53:22 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Fri, 12 Jun 2009 14:53:22 +0200 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <1B2CC34D-C3A2-4C7C-AF15-9749DCDD5ED8@cisco.com> Message-ID: Aswers below On Fri, 12 Jun 2009 05:09:51 -0700 Jeff Squyres wrote: > On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: > >> In your state diagram, you may differentiate between ticket author >> and chapter author. Please can you use a new color for the chapter- >> author trasitions. >> > > Can do. > >> If a reviewer detects a bug, he should set the state back to >> "Passed". A new color for the reviewer is also needed for this >> transition. >> > > I think that this is what I was thinking when I had an extra state >in my first diagram -- that the states would go between "text >committed" and "waiting for PDF reviews" until it was finally >"ticket complete". > > So do you want to make the reviewers responsible for changing the > state back away from "waiting for PDF reviews" to the previous >state? That would be different than what we did for proposals, >where the proposal author or chair would move the ticket between >"forum feedback requested", "not ready", and "waiting for (proposal) >reviews". Yes, because we have three parties: The ticket author who has only a controling role, the reviewers, and the chapter author. It must be absolutely sure, that the chapter author savely detects when he has to repair something. Therefore I would like that the status goes back to "Passed". This should be done by the reviewer as soon as he detects a problem. This reduces the risk, that something is overseen. The ticket author is doing only the final transition to "Ticket complete" after he and his 4 reviewers have checked the ticket-text in the MPI-2.2 standard. The ticket author may also be active, if the chapter author has not seen that a problem was detected and he has to repair something. Please, can you mention at the forward transition from "Passed" to "Waiting for PDF reviews": Set by a chapter author when all involved chapter authors have finished the MPI-2.2 latex text and produced a sniplet of pdf pages of this ticket. Please, can you mention at the backward transition from "Waiting for PDF reviews" to "Passed": Set back by a reviewer if he detects a bug in the pdf file. We must be sure, that all 85 tickets are handled correctly by the 13 chapter authors. Rolf > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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) From jsquyres at [hidden] Fri Jun 12 10:47:48 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Jun 2009 08:47:48 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: <84D9DCE6-4619-4046-A6C5-E6F7C071F12E@cisco.com> Ok, try this diagram. On Jun 12, 2009, at 5:53 AM, Rolf Rabenseifner wrote: > Aswers below > > On Fri, 12 Jun 2009 05:09:51 -0700 > Jeff Squyres wrote: > > On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: > > > >> In your state diagram, you may differentiate between ticket author > >> and chapter author. Please can you use a new color for the > chapter- > >> author trasitions. > >> > > > > Can do. > > > >> If a reviewer detects a bug, he should set the state back to > >> "Passed". A new color for the reviewer is also needed for this > >> transition. > >> > > > > I think that this is what I was thinking when I had an extra state > >in my first diagram -- that the states would go between "text > >committed" and "waiting for PDF reviews" until it was finally > >"ticket complete". > > > > So do you want to make the reviewers responsible for changing the > > state back away from "waiting for PDF reviews" to the previous > >state? That would be different than what we did for proposals, > >where the proposal author or chair would move the ticket between > >"forum feedback requested", "not ready", and "waiting for (proposal) > >reviews". > > Yes, because we have three parties: The ticket author who has only a > controling role, the reviewers, and the chapter author. > It must be absolutely sure, that the chapter author savely detects > when he has to repair something. Therefore I would like that > the status goes back to "Passed". This should be done by the reviewer > as soon as he detects a problem. This reduces the risk, that something > is overseen. > > The ticket author is doing only the final transition to "Ticket > complete" > after he and his 4 reviewers have checked the ticket-text in > the MPI-2.2 standard. > The ticket author may also be active, if the chapter author > has not seen that a problem was detected and he has to repair > something. > > Please, can you mention at the forward transition > from "Passed" to "Waiting for PDF reviews": > > Set by a chapter author when all involved chapter authors > have finished the MPI-2.2 latex text and produced a sniplet > of pdf pages of this ticket. > > Please, can you mention at the backward transition > from "Waiting for PDF reviews" to "Passed": > > Set back by a reviewer if he detects a bug in the pdf file. > > We must be sure, that all 85 tickets are handled correctly > by the 13 chapter authors. > > Rolf > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems * -------------- next part -------------- A non-text attachment was scrubbed... Name: MPI-2.2_ticket_states.pdf Type: application/pdf Size: 467281 bytes Desc: MPI-2.2_ticket_states.pdf URL: From rabenseifner at [hidden] Fri Jun 12 11:17:30 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Fri, 12 Jun 2009 18:17:30 +0200 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <84D9DCE6-4619-4046-A6C5-E6F7C071F12E@cisco.com> Message-ID: Jeff, For me, it is now perfect. I hope that all chapter authors are lucky with it. Rolf On Fri, 12 Jun 2009 08:47:48 -0700 Jeff Squyres wrote: > Ok, try this diagram. > > On Jun 12, 2009, at 5:53 AM, Rolf Rabenseifner wrote: > >> Aswers below >> >> On Fri, 12 Jun 2009 05:09:51 -0700 >> Jeff Squyres wrote: >> > On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: >> > >> >> In your state diagram, you may differentiate between ticket >>author >> >> and chapter author. Please can you use a new color for the >> chapter- >> >> author trasitions. >> >> >> > >> > Can do. >> > >> >> If a reviewer detects a bug, he should set the state back to >> >> "Passed". A new color for the reviewer is also needed for this >> >> transition. >> >> >> > >> > I think that this is what I was thinking when I had an extra state >> >in my first diagram -- that the states would go between "text >> >committed" and "waiting for PDF reviews" until it was finally >> >"ticket complete". >> > >> > So do you want to make the reviewers responsible for changing the >> > state back away from "waiting for PDF reviews" to the previous >> >state? That would be different than what we did for proposals, >> >where the proposal author or chair would move the ticket between >> >"forum feedback requested", "not ready", and "waiting for >>(proposal) >> >reviews". >> >> Yes, because we have three parties: The ticket author who has only a >> controling role, the reviewers, and the chapter author. >> It must be absolutely sure, that the chapter author savely detects >> when he has to repair something. Therefore I would like that >> the status goes back to "Passed". This should be done by the >>reviewer >> as soon as he detects a problem. This reduces the risk, that >>something >> is overseen. >> >> The ticket author is doing only the final transition to "Ticket >> complete" >> after he and his 4 reviewers have checked the ticket-text in >> the MPI-2.2 standard. >> The ticket author may also be active, if the chapter author >> has not seen that a problem was detected and he has to repair >> something. >> >> Please, can you mention at the forward transition >> from "Passed" to "Waiting for PDF reviews": >> >> Set by a chapter author when all involved chapter authors >> have finished the MPI-2.2 latex text and produced a sniplet >> of pdf pages of this ticket. >> >> Please, can you mention at the backward transition >> from "Waiting for PDF reviews" to "Passed": >> >> Set back by a reviewer if he detects a bug in the pdf file. >> >> We must be sure, that all 85 tickets are handled correctly >> by the 13 chapter authors. >> >> Rolf >> > >> > -- >> > Jeff Squyres >> > Cisco Systems >> > >> > _______________________________________________ >> > mpi-22 mailing list >> > mpi-22_at_[hidden] >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>rabenseifner_at_[hidden] >> 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-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > > > -- > Jeff Squyres > Cisco Systems Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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) From jsquyres at [hidden] Fri Jun 12 11:21:48 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 12 Jun 2009 09:21:48 -0700 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: <4452B34E-AA94-4F81-A291-C9F119080087@cisco.com> Ok. Let's get a few more approvals of this, and if everyone likes it, I'll add the extra states to Trac. On Jun 12, 2009, at 9:17 AM, Rolf Rabenseifner wrote: > Jeff, > For me, it is now perfect. > I hope that all chapter authors are lucky with it. > Rolf > > On Fri, 12 Jun 2009 08:47:48 -0700 > Jeff Squyres wrote: > > Ok, try this diagram. > > > > On Jun 12, 2009, at 5:53 AM, Rolf Rabenseifner wrote: > > > >> Aswers below > >> > >> On Fri, 12 Jun 2009 05:09:51 -0700 > >> Jeff Squyres wrote: > >> > On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: > >> > > >> >> In your state diagram, you may differentiate between ticket > >>author > >> >> and chapter author. Please can you use a new color for the > >> chapter- > >> >> author trasitions. > >> >> > >> > > >> > Can do. > >> > > >> >> If a reviewer detects a bug, he should set the state back to > >> >> "Passed". A new color for the reviewer is also needed for this > >> >> transition. > >> >> > >> > > >> > I think that this is what I was thinking when I had an extra > state > >> >in my first diagram -- that the states would go between "text > >> >committed" and "waiting for PDF reviews" until it was finally > >> >"ticket complete". > >> > > >> > So do you want to make the reviewers responsible for changing the > >> > state back away from "waiting for PDF reviews" to the previous > >> >state? That would be different than what we did for proposals, > >> >where the proposal author or chair would move the ticket between > >> >"forum feedback requested", "not ready", and "waiting for > >>(proposal) > >> >reviews". > >> > >> Yes, because we have three parties: The ticket author who has > only a > >> controling role, the reviewers, and the chapter author. > >> It must be absolutely sure, that the chapter author savely detects > >> when he has to repair something. Therefore I would like that > >> the status goes back to "Passed". This should be done by the > >>reviewer > >> as soon as he detects a problem. This reduces the risk, that > >>something > >> is overseen. > >> > >> The ticket author is doing only the final transition to "Ticket > >> complete" > >> after he and his 4 reviewers have checked the ticket-text in > >> the MPI-2.2 standard. > >> The ticket author may also be active, if the chapter author > >> has not seen that a problem was detected and he has to repair > >> something. > >> > >> Please, can you mention at the forward transition > >> from "Passed" to "Waiting for PDF reviews": > >> > >> Set by a chapter author when all involved chapter authors > >> have finished the MPI-2.2 latex text and produced a sniplet > >> of pdf pages of this ticket. > >> > >> Please, can you mention at the backward transition > >> from "Waiting for PDF reviews" to "Passed": > >> > >> Set back by a reviewer if he detects a bug in the pdf file. > >> > >> We must be sure, that all 85 tickets are handled correctly > >> by the 13 chapter authors. > >> > >> Rolf > >> > > >> > -- > >> > Jeff Squyres > >> > Cisco Systems > >> > > >> > _______________________________________________ > >> > mpi-22 mailing list > >> > mpi-22_at_[hidden] > >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>rabenseifner_at_[hidden] > >> 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-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > > > > > > -- > > Jeff Squyres > > Cisco Systems > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From wgropp at [hidden] Sat Jun 13 14:53:41 2009 From: wgropp at [hidden] (William Gropp) Date: Sat, 13 Jun 2009 14:53:41 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <4452B34E-AA94-4F81-A291-C9F119080087@cisco.com> Message-ID: <38F40F9E-1B62-4C26-AC5F-B352716D2021@illinois.edu> I prefer 2 (check boxes for each chapter author); the diagram is fine. I'm keeping a separate spreadsheet because it takes a *lot* less time to access the overall data that way. Bill On Jun 12, 2009, at 11:21 AM, Jeff Squyres wrote: > Ok. Let's get a few more approvals of this, and if everyone likes it, > I'll add the extra states to Trac. > > On Jun 12, 2009, at 9:17 AM, Rolf Rabenseifner wrote: > >> Jeff, >> For me, it is now perfect. >> I hope that all chapter authors are lucky with it. >> Rolf >> >> On Fri, 12 Jun 2009 08:47:48 -0700 >> Jeff Squyres wrote: >>> Ok, try this diagram. >>> >>> On Jun 12, 2009, at 5:53 AM, Rolf Rabenseifner wrote: >>> >>>> Aswers below >>>> >>>> On Fri, 12 Jun 2009 05:09:51 -0700 >>>> Jeff Squyres wrote: >>>>> On Jun 11, 2009, at 11:20 AM, Rolf Rabenseifner wrote: >>>>> >>>>>> In your state diagram, you may differentiate between ticket >>>> author >>>>>> and chapter author. Please can you use a new color for the >>>> chapter- >>>>>> author trasitions. >>>>>> >>>>> >>>>> Can do. >>>>> >>>>>> If a reviewer detects a bug, he should set the state back to >>>>>> "Passed". A new color for the reviewer is also needed for this >>>>>> transition. >>>>>> >>>>> >>>>> I think that this is what I was thinking when I had an extra >> state >>>>> in my first diagram -- that the states would go between "text >>>>> committed" and "waiting for PDF reviews" until it was finally >>>>> "ticket complete". >>>>> >>>>> So do you want to make the reviewers responsible for changing the >>>>> state back away from "waiting for PDF reviews" to the previous >>>>> state? That would be different than what we did for proposals, >>>>> where the proposal author or chair would move the ticket between >>>>> "forum feedback requested", "not ready", and "waiting for >>>> (proposal) >>>>> reviews". >>>> >>>> Yes, because we have three parties: The ticket author who has >> only a >>>> controling role, the reviewers, and the chapter author. >>>> It must be absolutely sure, that the chapter author savely detects >>>> when he has to repair something. Therefore I would like that >>>> the status goes back to "Passed". This should be done by the >>>> reviewer >>>> as soon as he detects a problem. This reduces the risk, that >>>> something >>>> is overseen. >>>> >>>> The ticket author is doing only the final transition to "Ticket >>>> complete" >>>> after he and his 4 reviewers have checked the ticket-text in >>>> the MPI-2.2 standard. >>>> The ticket author may also be active, if the chapter author >>>> has not seen that a problem was detected and he has to repair >>>> something. >>>> >>>> Please, can you mention at the forward transition >>>> from "Passed" to "Waiting for PDF reviews": >>>> >>>> Set by a chapter author when all involved chapter authors >>>> have finished the MPI-2.2 latex text and produced a sniplet >>>> of pdf pages of this ticket. >>>> >>>> Please, can you mention at the backward transition >>>> from "Waiting for PDF reviews" to "Passed": >>>> >>>> Set back by a reviewer if he detects a bug in the pdf file. >>>> >>>> We must be sure, that all 85 tickets are handled correctly >>>> by the 13 chapter authors. >>>> >>>> Rolf >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> Cisco Systems >>>>> >>>>> _______________________________________________ >>>>> mpi-22 mailing list >>>>> mpi-22_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>> >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>> rabenseifner_at_[hidden] >>>> 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-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>>> >>> >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> 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-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Tue Jun 16 13:50:54 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 16 Jun 2009 14:50:54 -0400 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <38F40F9E-1B62-4C26-AC5F-B352716D2021@illinois.edu> Message-ID: On Jun 13, 2009, at 3:53 PM, William Gropp wrote: > I prefer 2 (check boxes for each chapter author); the diagram is > fine. I'm keeping a separate spreadsheet because it takes a *lot* > less time to access the overall data that way. > I'm confused. I added the new states ("waiting for PDF reviews" / "ticket complete") and renamed the other two ("waiting for proposal reviews" / "proposal reviewed"), but do you want me to add the author checkboxes or not? FWIW: I think it'll be confusing if two different data systems are used to track the tickets (trac + a spreadsheet). -- Jeff Squyres Cisco Systems From wgropp at [hidden] Tue Jun 16 14:04:09 2009 From: wgropp at [hidden] (William Gropp) Date: Tue, 16 Jun 2009 14:04:09 -0500 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: Message-ID: <2F2E9D56-383A-4D0C-AC3E-A1A9810FD4D7@illinois.edu> I would like the author check boxes in addition to the new states; that makes it easier to keep track of who needs to be poked :) And FWIW, I'd also prefer to have a single data source, but I need one that will give me a quick overview of the state of the world (and would do so without giving me constant tracebacks). There's still info in my spreadsheet that isn't easily extracted from Trac. Bill On Jun 16, 2009, at 1:50 PM, Jeff Squyres wrote: > On Jun 13, 2009, at 3:53 PM, William Gropp wrote: > >> I prefer 2 (check boxes for each chapter author); the diagram is >> fine. I'm keeping a separate spreadsheet because it takes a *lot* >> less time to access the overall data that way. >> > > I'm confused. I added the new states ("waiting for PDF reviews" / > "ticket complete") and renamed the other two ("waiting for proposal > reviews" / "proposal reviewed"), but do you want me to add the author > checkboxes or not? > > FWIW: I think it'll be confusing if two different data systems are > used to track the tickets (trac + a spreadsheet). > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From jsquyres at [hidden] Tue Jun 16 14:09:55 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 16 Jun 2009 15:09:55 -0400 Subject: [Mpi-22] SVN committing MPI-2.2 latex In-Reply-To: <2F2E9D56-383A-4D0C-AC3E-A1A9810FD4D7@illinois.edu> Message-ID: <0E92E262-6E84-4450-AB11-DFD1005DCCE7@cisco.com> On Jun 16, 2009, at 3:04 PM, William Gropp wrote: > I would like the author check boxes in addition to the new states; > that makes it easier to keep track of who needs to be poked :) > Ok; I'll go add them. > And FWIW, I'd also prefer to have a single data source, but I need one > that will give me a quick overview of the state of the world (and > would do so without giving me constant tracebacks). There's still > info in my spreadsheet that isn't easily extracted from Trac. > Fair enough. -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Tue Jun 16 14:22:11 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 16 Jun 2009 15:22:11 -0400 Subject: [Mpi-22] Authors now on tickets Message-ID: <582C936B-FC97-4E51-AD8E-C0D063CE8A64@cisco.com> There are now checkboxes for the relevant chapter authors on the Trac tickets. You can use these fields in Trac custom queries to find tickets that are in your chapter (for example). Who is in charge of the Terms and Conventions chapter? On https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage , I see the following list, but it does not include T&C: Responsible Chapter Authors * Bill Gropp, Frontmatter, Introduction, and Bibliography * Richard Graham, Point-to-Point Communications * Adam Moody amd Torsten Hoefler, Collective Communication * Richard Treumann, Groups, Contexts, and Communicators * Jesper Larsson Traeff, Process Topologies, Info-Object, and One- Sided Communications * George Bosilca, Environmental Management * David Solt, Process Creation and Management * Bronis de Supinski, External Interfaces, and Profiling * Rajeev Thakur, I/O * Jeff Squyres, Language Bindings * Rolf Rabenseifner, Deprecated Functions, and Annex Change-Log * Alexander Supalov, Annex Language bindings -- Jeff Squyres Cisco Systems From wgropp at [hidden] Tue Jun 16 14:27:03 2009 From: wgropp at [hidden] (William Gropp) Date: Tue, 16 Jun 2009 14:27:03 -0500 Subject: [Mpi-22] Authors now on tickets In-Reply-To: <582C936B-FC97-4E51-AD8E-C0D063CE8A64@cisco.com> Message-ID: <88CCD5C7-5A50-4DBD-BD1D-BA6E7949A47F@illinois.edu> Thanks, Jeff. I'm in charge of T&C. Bill On Jun 16, 2009, at 2:22 PM, Jeff Squyres wrote: > There are now checkboxes for the relevant chapter authors on the Trac > tickets. > > You can use these fields in Trac custom queries to find tickets that > are in your chapter (for example). > > Who is in charge of the Terms and Conventions chapter? On https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage > , I see the following list, but it does not include T&C: > > Responsible Chapter Authors > > * Bill Gropp, Frontmatter, Introduction, and Bibliography > * Richard Graham, Point-to-Point Communications > * Adam Moody amd Torsten Hoefler, Collective Communication > * Richard Treumann, Groups, Contexts, and Communicators > * Jesper Larsson Traeff, Process Topologies, Info-Object, and One- > Sided Communications > * George Bosilca, Environmental Management > * David Solt, Process Creation and Management > * Bronis de Supinski, External Interfaces, and Profiling > * Rajeev Thakur, I/O > * Jeff Squyres, Language Bindings > * Rolf Rabenseifner, Deprecated Functions, and Annex Change-Log > * Alexander Supalov, Annex Language bindings > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From htor at [hidden] Wed Jun 17 10:59:08 2009 From: htor at [hidden] (Torsten Hoefler) Date: Wed, 17 Jun 2009 11:59:08 -0400 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) Message-ID: <20090617155908.GO1018@benten.cs.indiana.edu> Hello, everybody who abstained or voted against the proposal, please read ticket #33 and discuss any open issue or question either here or with me. I would be happy to answer any questions or address any doubts. A new implementation for all versions of the proposed scalable graph interface is attached to ticket #33 (virtual_graph_scal.cpp) (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33). This version does not implement the new interface on top of the old interface and thus reduces the memory consumption per process from O(N*N) to O(N) (assuming a reasonable specification). The implementation is trivial (took me about 2 hours) and the most complex function has 76 lines of code. The whole proposal including an example has 199 lines of code (many of this are interface definitions). As discussed, the communication overhead for the adjacent interface is zero and the worst-case communication overhead for the general interface is O(N) per process, however, the expected case is O(1) (constant). The attached implementation now achieves all goals of ticket #33, it increases the scalability of the graph interface by reducing the memory on the user-side to a lower complexity class and the communication is optimized. Ths significance of improvement is shown in the following table which lists the maximum memory consumption in bytes for different communicator sizes with the old and the new interface (assuming 8 byte integers). processes MPI-2.1 interface proposed interface 512 2 MiB 2 kiB 1024 8 MiB 8 kiB 4096 134 MiB 32 kiB 16384 2.1 GiB 131 kiB 65536 34.4 GiB 524 kiB This is an upper bound, if you are interested in sparse graphs, multiply both numbers by 0.01 (1% sparsity). The relative scaling remains the same. All issues related to process remapping are not part of the ticket and are not touched (the main intent of this ticket is to enable the use of virtual graph topologies at scale at all). However, if you are interested in this matter, there is an extensive body of research in this area: "Rank Reordering Strategy for MPI Topology Creation Functions" http://www.springerlink.com/content/f3hqq5u2v14tpu53/ "Topology mapping for Blue Gene/L supercomputer" http://portal.acm.org/citation.cfm?id=1188576 "Implementing the MPI process topology mechanism" http://portal.acm.org/citation.cfm?id=762761.762767 "Scheduling regular and irregular communication patterns on the CM-5" http://portal.acm.org/citation.cfm?id=147877.148034 Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler, Ph.D. | Postdoctoral Fellow Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608 From jsquyres at [hidden] Wed Jun 17 11:01:51 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 17 Jun 2009 12:01:51 -0400 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <20090617155908.GO1018@benten.cs.indiana.edu> Message-ID: <1EE99271-AE0B-4CB2-86D1-04A03445614E@cisco.com> Torsten -- Many thanks for your persistence in this ticket. From your description, it sounds like the implementation should be sufficient for many of those who abstained or voted against because it now does show tangible scalability improvements. All: please chime in if you feel this is not the case. #33 was perhaps the most "troublesome" ticket, so reaching consensus here would be great. Thanks! On Jun 17, 2009, at 11:59 AM, Torsten Hoefler wrote: > Hello, > everybody who abstained or voted against the proposal, please read > ticket #33 and discuss any open issue or question either here or > with me. > I would be happy to answer any questions or address any doubts. > > A new implementation for all versions of the proposed scalable graph > interface is attached to ticket #33 (virtual_graph_scal.cpp) > (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33). > > This version does not implement the new interface on top of the old > interface and thus reduces the memory consumption per process from > O(N*N) to O(N) (assuming a reasonable specification). > > The implementation is trivial (took me about 2 hours) and the most > complex function has 76 lines of code. The whole proposal including an > example has 199 lines of code (many of this are interface > definitions). > > As discussed, the communication overhead for the adjacent interface is > zero and the worst-case communication overhead for the general > interface > is O(N) per process, however, the expected case is O(1) (constant). > > The attached implementation now achieves all goals of ticket #33, it > increases the scalability of the graph interface by reducing the > memory > on the user-side to a lower complexity class and the communication is > optimized. > > Ths significance of improvement is shown in the following table which > lists the maximum memory consumption in bytes for different > communicator > sizes with the old and the new interface (assuming 8 byte integers). > > processes MPI-2.1 interface proposed interface > 512 2 MiB 2 kiB > 1024 8 MiB 8 kiB > 4096 134 MiB 32 kiB > 16384 2.1 GiB 131 kiB > 65536 34.4 GiB 524 kiB > > This is an upper bound, if you are interested in sparse graphs, > multiply > both numbers by 0.01 (1% sparsity). The relative scaling remains the > same. > > All issues related to process remapping are not part of the ticket and > are not touched (the main intent of this ticket is to enable the use > of > virtual graph topologies at scale at all). However, if you are > interested in this matter, there is an extensive body of research in > this area: > > "Rank Reordering Strategy for MPI Topology Creation Functions" > http://www.springerlink.com/content/f3hqq5u2v14tpu53/ > "Topology mapping for Blue Gene/L supercomputer" > http://portal.acm.org/citation.cfm?id=1188576 > "Implementing the MPI process topology mechanism" > http://portal.acm.org/citation.cfm?id=762761.762767 > "Scheduling regular and irregular communication patterns on the CM-5" > http://portal.acm.org/citation.cfm?id=147877.148034 > > Thanks & All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler, Ph.D. | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From alexander.supalov at [hidden] Thu Jun 18 02:47:34 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Thu, 18 Jun 2009 08:47:34 +0100 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <1EE99271-AE0B-4CB2-86D1-04A03445614E@cisco.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77EBBCBFC36@irsmsx504.ger.corp.intel.com> Hi everybody, Thanks, having a good prototype is definitely a great step forward. I hope that if we happen to have a couple of other MPI-2.2 tickets, the prototypes in which could be improved in a similar manner, their authors may find it possible to do so now. I wonder whether we may want to consider defining a prototype more strictly, say, by adding a couple of qualifiers like "demonstrating the intended functionality and performance potential" or something. This will definitely increase the quality of the prototypes, and may positively influence the quality of the resulting standard, which is after all what all of us are after here. Given that most of the intended MPI-2.2 tickets already appear to have good prototypes, it should not be a problem to clarify the rules a bit here. As was mentioned back in April, to facilitate commercial adoption of the MPI-2.2, it might also be good to resolve the ABI and IP matters at the same time, in application to this ticket and all other actual and potential MPI-2.2 entries. Even though it looks fairly unlikely that an addition of an extra class proposed in #33 will break anything in the C++ ABI, it just might. Hence, we need a determination by the Forum what kind of ABI changes is acceptable for MPI-2.2, possibly individually for each language binding, and what kind of procedure should be used to check the ABI backward compatibility where it is required - like testing, consultation with compiler writers, etc. A reasonable compromise wrt individual language bindings may help to ensure that the scope of the MPI-2.2 standard stays unchanged. The IP matter is basically a question of a license the prototype is being made available under. To simplify commercial adoption, it would be great to have the prototypes carry a BSD-style or an equally "commercial friendly" open source license. This may require some clarification on part of the authors with their respective institution, but by my records, the matter was in rather satisfactory state back in April. So, it should be no problem to make a slight change to the rules here either. I guess we should consider returning to these thee topics (prototype, ABI, IP) at the July meeting and making a decision there. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, June 17, 2009 6:02 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) Torsten -- Many thanks for your persistence in this ticket. From your description, it sounds like the implementation should be sufficient for many of those who abstained or voted against because it now does show tangible scalability improvements. All: please chime in if you feel this is not the case. #33 was perhaps the most "troublesome" ticket, so reaching consensus here would be great. Thanks! On Jun 17, 2009, at 11:59 AM, Torsten Hoefler wrote: > Hello, > everybody who abstained or voted against the proposal, please read > ticket #33 and discuss any open issue or question either here or > with me. > I would be happy to answer any questions or address any doubts. > > A new implementation for all versions of the proposed scalable graph > interface is attached to ticket #33 (virtual_graph_scal.cpp) > (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33). > > This version does not implement the new interface on top of the old > interface and thus reduces the memory consumption per process from > O(N*N) to O(N) (assuming a reasonable specification). > > The implementation is trivial (took me about 2 hours) and the most > complex function has 76 lines of code. The whole proposal including an > example has 199 lines of code (many of this are interface > definitions). > > As discussed, the communication overhead for the adjacent interface is > zero and the worst-case communication overhead for the general > interface > is O(N) per process, however, the expected case is O(1) (constant). > > The attached implementation now achieves all goals of ticket #33, it > increases the scalability of the graph interface by reducing the > memory > on the user-side to a lower complexity class and the communication is > optimized. > > Ths significance of improvement is shown in the following table which > lists the maximum memory consumption in bytes for different > communicator > sizes with the old and the new interface (assuming 8 byte integers). > > processes MPI-2.1 interface proposed interface > 512 2 MiB 2 kiB > 1024 8 MiB 8 kiB > 4096 134 MiB 32 kiB > 16384 2.1 GiB 131 kiB > 65536 34.4 GiB 524 kiB > > This is an upper bound, if you are interested in sparse graphs, > multiply > both numbers by 0.01 (1% sparsity). The relative scaling remains the > same. > > All issues related to process remapping are not part of the ticket and > are not touched (the main intent of this ticket is to enable the use > of > virtual graph topologies at scale at all). However, if you are > interested in this matter, there is an extensive body of research in > this area: > > "Rank Reordering Strategy for MPI Topology Creation Functions" > http://www.springerlink.com/content/f3hqq5u2v14tpu53/ > "Topology mapping for Blue Gene/L supercomputer" > http://portal.acm.org/citation.cfm?id=1188576 > "Implementing the MPI process topology mechanism" > http://portal.acm.org/citation.cfm?id=762761.762767 > "Scheduling regular and irregular communication patterns on the CM-5" > http://portal.acm.org/citation.cfm?id=147877.148034 > > Thanks & All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler, Ph.D. | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From jsquyres at [hidden] Thu Jun 18 06:03:06 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 18 Jun 2009 07:03:06 -0400 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EBBCBFC36@irsmsx504.ger.corp.intel.com> Message-ID: On Jun 18, 2009, at 3:47 AM, Supalov, Alexander wrote: > I wonder whether we may want to consider defining a prototype more > strictly, say, by adding a couple of qualifiers like "demonstrating > the intended functionality and performance potential" or something. > This will definitely increase the quality of the prototypes, and may > positively influence the quality of the resulting standard, which is > after all what all of us are after here. Given that most of the > intended MPI-2.2 tickets already appear to have good prototypes, it > should not be a problem to clarify the rules a bit here. > Actually, it would be better to make these "ad hoc" rules more definitive. Torsten is the latest in the series of people who have been bitten by thinking that they were acting by the rules but then someone said, "no, the rule is actually ..." Having somewhat subjective rules is fine, but having nebulous, not- written-down, sometimes-seemingly-arbitrary rules is what is causing a problem. How about someone making a shot at writing down exactly what the rules are? Leaving leeway for some subjectivity is fine (and good), but at leaving having *something* to point to when issues come under debate like this would be most helpful -- and will save a lot of time during the MPI-3 process. -- Jeff Squyres Cisco Systems From wgropp at [hidden] Thu Jun 18 12:52:48 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 18 Jun 2009 12:52:48 -0500 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: Message-ID: I've added my recollection of our various discussions on this to the wiki. These are the ones that I've applied as chair of the MPI 2.2 effort. Bill On Jun 18, 2009, at 6:03 AM, Jeff Squyres wrote: > On Jun 18, 2009, at 3:47 AM, Supalov, Alexander wrote: > >> I wonder whether we may want to consider defining a prototype more >> strictly, say, by adding a couple of qualifiers like "demonstrating >> the intended functionality and performance potential" or something. >> This will definitely increase the quality of the prototypes, and may >> positively influence the quality of the resulting standard, which is >> after all what all of us are after here. Given that most of the >> intended MPI-2.2 tickets already appear to have good prototypes, it >> should not be a problem to clarify the rules a bit here. >> > > > Actually, it would be better to make these "ad hoc" rules more > definitive. Torsten is the latest in the series of people who have > been bitten by thinking that they were acting by the rules but then > someone said, "no, the rule is actually ..." > > Having somewhat subjective rules is fine, but having nebulous, not- > written-down, sometimes-seemingly-arbitrary rules is what is causing a > problem. > > How about someone making a shot at writing down exactly what the rules > are? Leaving leeway for some subjectivity is fine (and good), but at > leaving having *something* to point to when issues come under debate > like this would be most helpful -- and will save a lot of time during > the MPI-3 process. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From htor at [hidden] Thu Jun 18 13:18:18 2009 From: htor at [hidden] (Torsten Hoefler) Date: Thu, 18 Jun 2009 14:18:18 -0400 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: Message-ID: <20090618181818.GS1018@benten.cs.indiana.edu> On Thu, Jun 18, 2009 at 12:52:48PM -0500, William Gropp wrote: > I've added my recollection of our various discussions on this to the > wiki. These are the ones that I've applied as chair of the MPI 2.2 > effort. Thank you very much for this clarification Bill! I think/hope we all agree on this. Ticket #33 fulfills guideline 3. I also attached a BSD-like (that's what the lawyers at IU said) license file to all my implementations (#24, #31, #33, #94). Could everybody who is concerned with licensing issues (Alexander, Erez) please check the license and tell me if this is ok for you? Everybody else, please look carefully at ticket #33 and direct any questions and/or critics to me. Thanks! Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler, Ph.D. | Postdoctoral Fellow Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608 From alexander.supalov at [hidden] Thu Jun 18 13:50:49 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Thu, 18 Jun 2009 19:50:49 +0100 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <20090618181818.GS1018@benten.cs.indiana.edu> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77EBBD0115C@irsmsx504.ger.corp.intel.com> Hi, Thanks. I'm not sure what part of the Wiki is meant when the guidelines are mentioned. Is it "Some guidelines for submissions" at the top of https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage ? If so, I'm can't see ABI compatibility there yet, only backward compatibility in the sense that "it must not break existing correct programs" that may be understood as "recompile and enjoy". However, a forced recompilation is not what some customers will enjoy. Something mode definite, like "The intention of the Forum is that MPI-2.2 C and Fortran interfaces stay binary compatible with their MPI-2.1 counterparts" would probably suffice to address this. Note that C++ is intentionally omitted here. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Torsten Hoefler Sent: Thursday, June 18, 2009 8:18 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) On Thu, Jun 18, 2009 at 12:52:48PM -0500, William Gropp wrote: > I've added my recollection of our various discussions on this to the > wiki. These are the ones that I've applied as chair of the MPI 2.2 > effort. Thank you very much for this clarification Bill! I think/hope we all agree on this. Ticket #33 fulfills guideline 3. I also attached a BSD-like (that's what the lawyers at IU said) license file to all my implementations (#24, #31, #33, #94). Could everybody who is concerned with licensing issues (Alexander, Erez) please check the license and tell me if this is ok for you? Everybody else, please look carefully at ticket #33 and direct any questions and/or critics to me. Thanks! Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler, Ph.D. | Postdoctoral Fellow Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From wgropp at [hidden] Thu Jun 18 16:29:10 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 18 Jun 2009 16:29:10 -0500 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EBBD0115C@irsmsx504.ger.corp.intel.com> Message-ID: <1E10B92E-2BB5-48E2-92D6-2FF1EAE6D4FF@illinois.edu> The ABI issue is one that is important but was not part of the original requirements (I went back to the original slides kicking off the 2.2 effort). It certainly is something to consider, and I agree that it is best to avoid ABI changes if possible. And this might be something that we should have specified at the beginning of the 2.2 (or 2.1) process, but we didn't. Fortunately, for Fortran and C (but not C++), the other requirements should make it possible for an implementation to meet this requirement. Bill On Jun 18, 2009, at 1:50 PM, Supalov, Alexander wrote: > Hi, > > Thanks. I'm not sure what part of the Wiki is meant when the > guidelines are mentioned. Is it "Some guidelines for submissions" at > the top of https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage > ? > > If so, I'm can't see ABI compatibility there yet, only backward > compatibility in the sense that "it must not break existing correct > programs" that may be understood as "recompile and enjoy". However, > a forced recompilation is not what some customers will enjoy. > > Something mode definite, like "The intention of the Forum is that > MPI-2.2 C and Fortran interfaces stay binary compatible with their > MPI-2.1 counterparts" would probably suffice to address this. Note > that C++ is intentionally omitted here. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Torsten Hoefler > Sent: Thursday, June 18, 2009 8:18 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) > > On Thu, Jun 18, 2009 at 12:52:48PM -0500, William Gropp wrote: >> I've added my recollection of our various discussions on this to the >> wiki. These are the ones that I've applied as chair of the MPI 2.2 >> effort. > Thank you very much for this clarification Bill! I think/hope we all > agree on this. > > Ticket #33 fulfills guideline 3. I also attached a BSD-like (that's > what > the lawyers at IU said) license file to all my implementations (#24, > #31, #33, #94). > > Could everybody who is concerned with licensing issues (Alexander, > Erez) > please check the license and tell me if this is ok for you? > > Everybody else, please look carefully at ticket #33 and direct any > questions and/or critics to me. > > Thanks! > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler, Ph.D. | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From alexander.supalov at [hidden] Fri Jun 19 04:12:36 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 19 Jun 2009 10:12:36 +0100 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <1E10B92E-2BB5-48E2-92D6-2FF1EAE6D4FF@illinois.edu> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77EBBD012E5@irsmsx504.ger.corp.intel.com> Thanks. If we decide to deprecate C++ binding, will it still be updated in the standard to expose the new MPI-2.2 features, or will it be frozen at the MPI-2.1 level? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Thursday, June 18, 2009 11:29 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) The ABI issue is one that is important but was not part of the original requirements (I went back to the original slides kicking off the 2.2 effort). It certainly is something to consider, and I agree that it is best to avoid ABI changes if possible. And this might be something that we should have specified at the beginning of the 2.2 (or 2.1) process, but we didn't. Fortunately, for Fortran and C (but not C++), the other requirements should make it possible for an implementation to meet this requirement. Bill On Jun 18, 2009, at 1:50 PM, Supalov, Alexander wrote: > Hi, > > Thanks. I'm not sure what part of the Wiki is meant when the > guidelines are mentioned. Is it "Some guidelines for submissions" at > the top of https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage > ? > > If so, I'm can't see ABI compatibility there yet, only backward > compatibility in the sense that "it must not break existing correct > programs" that may be understood as "recompile and enjoy". However, > a forced recompilation is not what some customers will enjoy. > > Something mode definite, like "The intention of the Forum is that > MPI-2.2 C and Fortran interfaces stay binary compatible with their > MPI-2.1 counterparts" would probably suffice to address this. Note > that C++ is intentionally omitted here. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Torsten Hoefler > Sent: Thursday, June 18, 2009 8:18 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) > > On Thu, Jun 18, 2009 at 12:52:48PM -0500, William Gropp wrote: >> I've added my recollection of our various discussions on this to the >> wiki. These are the ones that I've applied as chair of the MPI 2.2 >> effort. > Thank you very much for this clarification Bill! I think/hope we all > agree on this. > > Ticket #33 fulfills guideline 3. I also attached a BSD-like (that's > what > the lawyers at IU said) license file to all my implementations (#24, > #31, #33, #94). > > Could everybody who is concerned with licensing issues (Alexander, > Erez) > please check the license and tell me if this is ok for you? > > Everybody else, please look carefully at ticket #33 and direct any > questions and/or critics to me. > > Thanks! > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler, Ph.D. | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From jsquyres at [hidden] Fri Jun 19 05:31:55 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 19 Jun 2009 06:31:55 -0400 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EBBD012E5@irsmsx504.ger.corp.intel.com> Message-ID: <5A0CB794-A7CF-47EE-9FD5-8CC8BFA04F87@cisco.com> On Jun 19, 2009, at 5:12 AM, Supalov, Alexander wrote: > Thanks. If we decide to deprecate C++ binding, will it still be > updated in the standard to expose the new MPI-2.2 features, or will > it be frozen at the MPI-2.1 level? > I'd be in favor of freezing it at 2.1 level -- then many of these ABI issues go away. -- Jeff Squyres Cisco Systems From wgropp at [hidden] Fri Jun 19 10:19:21 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 19 Jun 2009 10:19:21 -0500 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <5A0CB794-A7CF-47EE-9FD5-8CC8BFA04F87@cisco.com> Message-ID: <214B93BC-D7D0-4123-AADE-E9EB6BD7AD91@illinois.edu> Deprecated doesn't mean removed - we will need some C++ binding for the new features. Bill On Jun 19, 2009, at 5:31 AM, Jeff Squyres wrote: > On Jun 19, 2009, at 5:12 AM, Supalov, Alexander wrote: > >> Thanks. If we decide to deprecate C++ binding, will it still be >> updated in the standard to expose the new MPI-2.2 features, or will >> it be frozen at the MPI-2.1 level? >> > > I'd be in favor of freezing it at 2.1 level -- then many of these ABI > issues go away. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From bwbarre at [hidden] Fri Jun 19 10:51:15 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Fri, 19 Jun 2009 09:51:15 -0600 Subject: [Mpi-22] Ticket #33 (Scalable Graph Topology Interface) In-Reply-To: <214B93BC-D7D0-4123-AADE-E9EB6BD7AD91@illinois.edu> Message-ID: I agree with Bill - I think we should continue to extend the C++ bindings with new interfaces until at least 3.0. I think it would be very weird for users if a feature was available in C and Fortran and not C++. That being said, I also think the whole ABI thing is a nice goal, but not one of the original requirements of the 2.x process, so if something could maybe on some platform break the ABI compatibility for the C++ bindings, that should not be disqualifying for the 2.2 process. Brian On 6/19/09 9:19 , "William Gropp" wrote: > Deprecated doesn't mean removed - we will need some C++ binding for > the new features. > > Bill > > On Jun 19, 2009, at 5:31 AM, Jeff Squyres wrote: > >> On Jun 19, 2009, at 5:12 AM, Supalov, Alexander wrote: >> >>> Thanks. If we decide to deprecate C++ binding, will it still be >>> updated in the standard to expose the new MPI-2.2 features, or will >>> it be frozen at the MPI-2.1 level? >>> >> >> I'd be in favor of freezing it at 2.1 level -- then many of these ABI >> issues go away. >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories