June 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] SVN committing MPI-2.2 latex
by unknown＠example.com 11 Jun '09

11 Jun '09

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 *

1 0

Re: [Mpi-22] SVN committing MPI-2.2 latex
by unknown＠example.com 11 Jun '09

11 Jun '09

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 > <MPI-2.2 ticket states-suggested.pdf><ATT00001.txt> 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

1 0

Re: [Mpi-22] SVN committing MPI-2.2 latex
by unknown＠example.com 11 Jun '09

11 Jun '09

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 > > <MPI-2.2 ticket states-suggested.pdf><ATT00001.txt> > > 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

1 0

Re: [Mpi-22] SVN committing MPI-2.2 latex
by unknown＠example.com 11 Jun '09

11 Jun '09

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 > <MPI-2.2 ticket states-suggested.pdf><ATT00001.txt> 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

1 0

SVN committing MPI-2.2 latex
by unknown＠example.com 11 Jun '09

11 Jun '09

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 *

1 0

Re: [Mpi-22] [MPI Forum] #37: Clarify semantics of one-sided semantics when changing synchronization mode
by unknown＠example.com 08 Jun '09

08 Jun '09

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: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/37#comment:33> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum *

1 0

Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140
by unknown＠example.com 05 Jun '09

05 Jun '09

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]<mailto: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]<mailto: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 > > > > <ATT00001.txt> > > > > 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 >

1 0

Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140
by unknown＠example.com 05 Jun '09

05 Jun '09

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]<mailto: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]<mailto: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 > > > <ATT00001.txt> > > > > > > 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

1 0

Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140
by unknown＠example.com 02 Jun '09

02 Jun '09

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]<mailto: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]<mailto: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 > > <ATT00001.txt> > > > > 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 *

1 0

Re: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140
by unknown＠example.com 01 Jun '09

01 Jun '09

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]> [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]<mailto: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 > <ATT00001.txt> > > 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 > > > > > >

1 0