From bronis at [hidden] Tue Nov 2 12:23:08 2010 From: bronis at [hidden] (Bronis R. de Supinski) Date: Tue, 2 Nov 2010 10:23:08 -0700 (PDT) Subject: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations In-Reply-To: <051.f786724a087c9dc373d02bc4e79d1201@lists.mpi-forum.org> Message-ID: Rolf and Torsten: It really seems to me that these changes exceed the guidelines that Rich and Bill have given for the release draft. While I understand the reasoon behind them, it is unclear that we will have reviewed them properly. For example, I think the wording below could use work. I am in transit to ANL right now so I cannot go over it properly until at least tonight... Even then, this feels rushed. Bronis On Tue, 2 Nov 2010, MPI Forum wrote: > #109: Nonblocking Collective Operations > --------------------------------------------------------+------------------- > Reporter: htor | Owner: htor > Type: New routine(s) | Status: new > Priority: Waiting for PDF reviews | Milestone: 2009/02/09 San Jose > Version: MPI 3.0 | Keywords: > Implementation: Completed | Author_bill_gropp: 1 > Author_rich_graham: 0 | Author_adam_moody: 0 > Author_torsten_hoefler: 1 | Author_dick_treumann: 0 > Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0 > Author_david_solt: 0 | Author_bronis_de_supinski: 0 > Author_rajeev_thakur: 0 | Author_jeff_squyres: 0 > Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 1 > --------------------------------------------------------+------------------- > > Comment(by htor): > > Replying to [comment:44 RolfRabenseifner]: > > Whether we use now the text in my last comment or, a more complete text, > > we can decide now or later, but I would prefer a more complete text, > > because then it is clear why this exception is only for 4 completion > routines: > > > > The fields in a status object returned by a call to MPI_WAIT, > MPI_TEST, or > > MPI_{TEST|WAIT}{ALL|SOME|ANY}, where the request corresponds to a > nonblocking > > collective call, are undefined, with one exceptions: The error status > field > > will contain valid information if the wait or test call returned with > MPI_ERR_IN_STATUS. > > MPI_ERR_IN_STATUS can be returned only by MPI_{TEST|WAIT}{ALL|SOME}, > because > > only these MPI completion functions take arrays of MPI_STATUS. > > Rolf and I decided to adopt this minor change (with slight modifications) > and clear fix after a phone call. It now reads: > > "The fields in a status object returned by a call to MPI_WAIT, MPI_TEST, > or any of the other derived functions (MPI_{TEST|WAIT}{ALL|SOME|ANY}), > where the request corresponds to a send call, are undefined, with one > exception: The error status field will contain valid information if the > wait or test call returned with MPI_ERR_IN_STATUS. MPI_ERR_IN_STATUS > should be returned only by MPI_{TEST|WAIT}{ALL|SOME}, because only these > MPI completion functions take arrays of MPI_STATUS." > > See revision 679. > > Thanks, > Torsten > > -- > Ticket URL: > MPI Forum > MPI Forum From htor at [hidden] Tue Nov 2 12:31:16 2010 From: htor at [hidden] (Torsten Hoefler) Date: Tue, 2 Nov 2010 12:31:16 -0500 Subject: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations In-Reply-To: Message-ID: <20101102173116.GV15420@benten.cs.indiana.edu> Bronis, > It really seems to me that these changes exceed > the guidelines that Rich and Bill have given > for the release draft. While I understand the > reasoon behind them, it is unclear that we will > have reviewed them properly. For example, I think > the wording below could use work. This is a clear error and can cause significant confusion on the user's and implementer's side. Most of the text is copied from the point-to-point section and is thus consistent with the remainder of the document (even though I don't like the wording there ("should") at all!). > I am in transit to ANL right now so I cannot go > over it properly until at least tonight... Please take your time and check. We are not intending to rush. > Even then, this feels rushed. I don't think there is rush. We can release the document without this fix (with a known bug). That's why I commit each item separately. However, I'm against a release with bugs but that's not my decision. Thanks, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736 From rabenseifner at [hidden] Wed Nov 3 03:55:49 2010 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Wed, 3 Nov 2010 09:55:49 +0100 (CET) Subject: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations In-Reply-To: <20101102173116.GV15420@benten.cs.indiana.edu> Message-ID: <12021157.20765.1288774549672.JavaMail.root@epsilon> Bronis, the corrections are based on the primary rule that the job of the chapter committee is to guarantee that a new functionality is included in the document in a consistent way. This was done. This was not a correction of the functionality of the nonblocking collective communications. Ticket 109 is the only one that was included and only for this ticket, such consistency checks had to be done. For all other chapters, the rule is "only typo and formatting corrections". Rolf ----- Original Message ----- > From: "Torsten Hoefler" > To: "Bronis R. de Supinski" , "MPI 2.2" > Sent: Tuesday, November 2, 2010 6:31:16 PM > Subject: Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations > Bronis, > > It really seems to me that these changes exceed > > the guidelines that Rich and Bill have given > > for the release draft. While I understand the > > reasoon behind them, it is unclear that we will > > have reviewed them properly. For example, I think > > the wording below could use work. > This is a clear error and can cause significant confusion on the > user's > and implementer's side. Most of the text is copied from the > point-to-point section and is thus consistent with the remainder of > the > document (even though I don't like the wording there ("should") at > all!). > > > I am in transit to ANL right now so I cannot go > > over it properly until at least tonight... > Please take your time and check. We are not intending to rush. > > > Even then, this feels rushed. > I don't think there is rush. We can release the document without this > fix (with a known bug). That's why I commit each item separately. > However, I'm against a release with bugs but that's not my decision. > > Thanks, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > 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 wgropp at [hidden] Wed Nov 3 10:23:14 2010 From: wgropp at [hidden] (William Gropp) Date: Wed, 3 Nov 2010 10:23:14 -0500 Subject: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations In-Reply-To: <20101102173116.GV15420@benten.cs.indiana.edu> Message-ID: Here's my suggestion: The draft is intended to alert people to very likely additions and even changes to the MPI standard. The draft should be in as good a shape as possible, so fixes like this to the text are reasonable. However, these are significant enough that for the Standard (not the draft), we'll clearly need another vote. We should postpone that vote until we're closer to issuing an official standard, since other things may change (for example, C++ or Fortran 200x bindings). Bill On Nov 2, 2010, at 12:31 PM, Torsten Hoefler wrote: > Bronis, >> It really seems to me that these changes exceed >> the guidelines that Rich and Bill have given >> for the release draft. While I understand the >> reasoon behind them, it is unclear that we will >> have reviewed them properly. For example, I think >> the wording below could use work. > This is a clear error and can cause significant confusion on the > user's > and implementer's side. Most of the text is copied from the > point-to-point section and is thus consistent with the remainder of > the > document (even though I don't like the wording there ("should") at > all!). > >> I am in transit to ANL right now so I cannot go >> over it properly until at least tonight... > Please take your time and check. We are not intending to rush. > >> Even then, this feels rushed. > I don't think there is rush. We can release the document without this > fix (with a known bug). That's why I commit each item separately. > However, I'm against a release with bugs but that's not my decision. > > Thanks, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > 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