- Mpi-21 - mailman3.cels.anl.gov

Re: [mpi-21] Ballot 4 proposal: MPI::COMM_WORLD and MPI::COMM_SELF should be const
by unknown＠example.com 21 Jan '08

21 Jan '08

On Jan 21, 2008, at 10:40 AM, Jeff Squyres wrote: > Not that many other predefined MPI C++ handles are already const; ... Gaa! That should be "Note" (vs. "Not"). That somewhat changes the meaning of the sentence. :-) -- Jeff Squyres Cisco Systems

1 0

Ballot 4 proposal: MPI::COMM_WORLD and MPI::COMM_SELF should be const
by unknown＠example.com 21 Jan '08

21 Jan '08

This is not already on Bill's errata page. Proposal: Make MPI::COMM_WORLD and MPI::COMM_SELF be "const". Change MPI-2:B.2 p345:18 from // Type: MPI::Intracomm to // Type: const MPI::Intracomm Rationale: The COMM_WORLD and COMM_SELF C++ handles were erroneously not marked "const" because of the incorrect INOUT MPI handle parameter designation of the MPI_COMM_SET_ERRHANDLER, MPI_COMM_SET_ATTR, and MPI_COMM_SET_ERRHANDLER functions. This caused the C++ bindings methods to not be const, resulting in compile errors if COMM_WORLD was const and you invoked any of the methods listed above (e.g., MPI::COMM_WORLD.Set_errhandler(...)). The proper solution is to have all the MPI handle arguments be IN instead of INOUT (covered in another proposal) and therefore have the Set_* functions be const (also covered that other proposal). Once that solution is in place, COMM_WORLD and COMM_SELF should be marked as "const". Not that many other predefined MPI C++ handles are already const; some erroneously had their "const" designation removed in ballot 2 -- a different proposal seeks to restore their "const" status. NOTE: This proposal depends on the "change some INOUT parameters to IN" proposal. -- Jeff Squyres Cisco Systems

1 0

Ballot 4 proposal: "const" predefined MPI C++ handles
by unknown＠example.com 21 Jan '08

21 Jan '08

This is not already on Bill's errata page. Proposal: ballot 2 removed "const" from several predefined MPI C++ handles. This was incorrect; they should have been left const. Remove text from the "Updated MPI-2.0 errata" document: p7:33-41. NOTE: this proposal is dependent upon the proposal to change some INOUT parameters to IN and add "const" to the corresponding C++ methods. -- Jeff Squyres Cisco Systems

1 0

Ballot 4 proposal: INOUT arguments
by unknown＠example.com 21 Jan '08

21 Jan '08

This is not already on Bill's errata page. Proposal: change the INOUT designation of the MPI handle parameters in several MPI-2 functions to be IN, because the values of the handles are not changing. Only the underlying MPI objects are changing. The C bindings for each of these functions do *not* pass the MPI handle by reference, therefore disallowing the possibility of these parameters actually being INOUT. By the same argument, the C++ methods for these functions should be const since the C++ object invoking the method will not be changed. The functions in question are: MPI_*_SET_NAME for communicators, datatypes, windows MPI_*_SET_ATTR for communicators, datatypes, windows MPI_*_SET_ERRHANDLER for communicators, files, windows Locations of specific text to be changed (INOUT -> IN, add "const" to C ++ methods): MPI_COMM_SET_NAME: MPI-2:8.4, p177:35,44 MPI-2:A.8.5, p336:28 MPI_TYPE_SET_NAME: MPI-2:8.4, p179:41, p180:2 MPI-2:A.8.5, p337:2 MPI_WIN_SET_NAME: MPI-2:8.4, p181:25,35 MPI-2:A.8.5, p337:36 MPI_COMM_SET_ATTR: MPI-2:8.8.1, p201:6,17 MPI-2:A.8.5, p336:27 MPI_WIN_SET_ATTR: MPI-2:8.8.2, p204:2,12 MPI-2:A.8.5, p337:35 MPI_TYPE_SET_ATTR: MPI-2:8.8.3, p206:26,37 MPI-2:A.8.5, p337:1 MPI_COMM_SET_ERRHANDLER: MPI-2:4.13.1, p62:35,43 MPI-2:A.8.1, p331:38 MPI_WIN_SET_ERRHANDLER: MPI-2:4.13.2, p64:2,10 MPI-2:A.8.1, p333:13 MPI_FILE_SET_ERRHANDLER: MPI-2:4.13.3, p65:14,22 MPI-2:A.8.1, p332:34 NOTE: The "const" issues of this proposal will be dependent upon a 2nd proposal about re-instituting the "const" on MPI predefined handles that was removed in ballot 2. -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 21 Jan '08

21 Jan '08

We'll put it on Ballot 4. It finishes two discussion streams: ----------------------------------------- Interlanguage use of Attributes http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Subject: Re: clarification on inter-language interoperability of attributes See also Error in Example 4.13 in MPI-2 Error in Example 4.13 in MPI-2 (Use of Attributes in C and Fortran) http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Subject: MPI-2 attributes question See also Interlanguage use of Attributes. ----------------------------------------- I checked again all the cross references in MPI-1 and MPI-2. It seems that this was the only inconsistency on attribute caching Fortran and C interfaces. Best regards Rolf On Fri, 18 Jan 2008 16:10:49 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >Per http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ , the errata item entitled "Error in Example 4.13 in MPI-2 (Use of Attributes in C and Fortran)". I believe that this errata item supersedes the errata item "Interlanguage use of Attributes". > >See the mail discussing: > >http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > >Proposal: > >Change MPI-2:4.12, p58:36 from: > IF (val.NE.5) THEN CALL ERROR >to > IF (val.NE.address_of_i) THEN CALL ERROR > >Rationale: > >MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is set by C, retrieving it in Fortran will obtain the address of the attribute. > >See the mails for more discussion, including an exhaustive list of what happens for each of the 9 possibilities of setting and getting attribute values between the different languages. > >-- >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)

1 0

Re: [mpi-21] MPI-2.1, 1-sided and MPI_PROC_NULL --> Ballot 4
by unknown＠example.com 21 Jan '08

21 Jan '08

This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: MPI_PROCNULL and RMA Part 2 in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Proposal for MPI 2.1, Ballot 4: ------------------------------- Proposed text MPI-2, page 114, after line 4 (and after the lines added about MPI_PROC_NULL), add After an RMA operations with rank MPI_PROC_NULL, it is still necessary to finish the RMA epoch with the synchronization method that has started the epoch. ------------------------------- Reason: With Ballot 2, the Forum included MPI_PROC_NULL also in RMA calls. The proposed text clarifies a till exiting open question. ------------------------------- Discussion should be done through the new mailing list mpi-21_at_cs.uiuc.edu. I have sent out this mail with CC through the old general list mpi-21_at_[hidden] Best regards Rolf 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)

1 0

Re: [mpi-21] const C++ MPI handles (take 2)
by unknown＠example.com 19 Jan '08

19 Jan '08

Because I have a mail proposal pending to restore the "const" that was [erroneously, IMHO] removed in ballot 2. :-D On Jan 19, 2008, at 5:59 PM, Erez Haba wrote: > If the 'const' was removed in ballot 2 whey do you want to leave the > text that refers to it? > > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Saturday, January 19, 2008 11:17 AM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: Re: [mpi-21] const C++ MPI handles (take 2) > > Well, we pretty much have so far. :-) > > The const was removed in ballot 2, but I wonder how many people > actually noticed (I didn't, until a few days ago). > > > > On Jan 19, 2008, at 1:21 PM, Erez Haba wrote: > >> I agree, const is the better way to implement. The question is: do >> you want to *force* the optimized implementation? >> >> -----Original Message----- >> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] >> On Behalf Of Jeff Squyres >> Sent: Friday, January 18, 2008 5:49 PM >> To: mpi-21_at_[hidden] >> Cc: mpi-21_at_[hidden] >> Subject: Re: [mpi-21] const C++ MPI handles (take 2) >> >> Yes, that's the way the original C++ bindings were implemented. But >> it's not required or necessary to do that; that C errhandler could >> easily be cached somewhere else. >> >> More specifically, isn't it better to have a const object to allow >> for >> compiler optimizations? (I'm not a compiler guru, but I thought the >> point of why we originally made the C++ handles be const was on the >> argument for potential compiler optimizations) >> >> >> On Jan 18, 2008, at 8:35 PM, Erez Haba wrote: >> >>> For example an implementation might choose to cache the error >>> handler for MPI::COMM_WORD (in the MPI::Comm object) and call it >>> itself on error so it can pass in the right object to the error >>> handler. >>> Thus requiring MPI::COMM_WORLD not to be const. >>> >>> >>> -----Original Message----- >>> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] >>> On Behalf Of Jeff Squyres >>> Sent: Friday, January 18, 2008 11:14 AM >>> To: mpi-21_at_[hidden] >>> Cc: mpi-21_at_[hidden] >>> Subject: [mpi-21] const C++ MPI handles (take 2) >>> >>> On Jan 18, 2008, at 2:02 PM, Erez Haba wrote: >>> >>>> Okay; about one issue at a time. >>> >>> Changing mail subject to reflect the discussion... >>> >>>> *For this sentence* it does not matter what's a common usage for C >>>> ++ >>>> global variables. Some MPI implementations would need to have non- >>>> const qualified global objects. >>> >>> Why? As I understand it, most (all?) MPI C++ implementations >>> currently only require some objects to be non-const because of the >>> standard-related issue that was already raised (Set_attr(), >>> Set_name(), Set_errhandler() methods not having const variants). Is >>> there a reason that an implementation would *need* MPI handles to be >>> non-const? >>> >>> Per my prior mail, I believe that the standard should specify that >>> some of the methods on these classes should have const and non-const >>> variants, and then it should be fine to require that the predefined >>> handles be const. >>> >>> So the question is still open: what's common practice in the C++ >>> community regarding const/non-const global variable specification? >>> This question will be moot if you can demonstrate that an >>> implementation would need non-const C++ MPI predefined handles. >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >> >> >> -- >> Jeff Squyres >> Cisco Systems >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] const C++ MPI handles (take 2)
by unknown＠example.com 19 Jan '08

19 Jan '08

If the 'const' was removed in ballot 2 whey do you want to leave the text that refers to it? -----Original Message----- From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, January 19, 2008 11:17 AM To: mpi-21_at_[hidden] Cc: mpi-21_at_[hidden] Subject: Re: [mpi-21] const C++ MPI handles (take 2) Well, we pretty much have so far. :-) The const was removed in ballot 2, but I wonder how many people actually noticed (I didn't, until a few days ago). On Jan 19, 2008, at 1:21 PM, Erez Haba wrote: > I agree, const is the better way to implement. The question is: do > you want to *force* the optimized implementation? > > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Friday, January 18, 2008 5:49 PM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: Re: [mpi-21] const C++ MPI handles (take 2) > > Yes, that's the way the original C++ bindings were implemented. But > it's not required or necessary to do that; that C errhandler could > easily be cached somewhere else. > > More specifically, isn't it better to have a const object to allow for > compiler optimizations? (I'm not a compiler guru, but I thought the > point of why we originally made the C++ handles be const was on the > argument for potential compiler optimizations) > > > On Jan 18, 2008, at 8:35 PM, Erez Haba wrote: > >> For example an implementation might choose to cache the error >> handler for MPI::COMM_WORD (in the MPI::Comm object) and call it >> itself on error so it can pass in the right object to the error >> handler. >> Thus requiring MPI::COMM_WORLD not to be const. >> >> >> -----Original Message----- >> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] >> On Behalf Of Jeff Squyres >> Sent: Friday, January 18, 2008 11:14 AM >> To: mpi-21_at_[hidden] >> Cc: mpi-21_at_[hidden] >> Subject: [mpi-21] const C++ MPI handles (take 2) >> >> On Jan 18, 2008, at 2:02 PM, Erez Haba wrote: >> >>> Okay; about one issue at a time. >> >> Changing mail subject to reflect the discussion... >> >>> *For this sentence* it does not matter what's a common usage for C++ >>> global variables. Some MPI implementations would need to have non- >>> const qualified global objects. >> >> Why? As I understand it, most (all?) MPI C++ implementations >> currently only require some objects to be non-const because of the >> standard-related issue that was already raised (Set_attr(), >> Set_name(), Set_errhandler() methods not having const variants). Is >> there a reason that an implementation would *need* MPI handles to be >> non-const? >> >> Per my prior mail, I believe that the standard should specify that >> some of the methods on these classes should have const and non-const >> variants, and then it should be fine to require that the predefined >> handles be const. >> >> So the question is still open: what's common practice in the C++ >> community regarding const/non-const global variable specification? >> This question will be moot if you can demonstrate that an >> implementation would need non-const C++ MPI predefined handles. >> >> -- >> Jeff Squyres >> Cisco Systems >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] const C++ MPI handles (take 2)
by unknown＠example.com 19 Jan '08

19 Jan '08

Well, we pretty much have so far. :-) The const was removed in ballot 2, but I wonder how many people actually noticed (I didn't, until a few days ago). On Jan 19, 2008, at 1:21 PM, Erez Haba wrote: > I agree, const is the better way to implement. The question is: do > you want to *force* the optimized implementation? > > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Friday, January 18, 2008 5:49 PM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: Re: [mpi-21] const C++ MPI handles (take 2) > > Yes, that's the way the original C++ bindings were implemented. But > it's not required or necessary to do that; that C errhandler could > easily be cached somewhere else. > > More specifically, isn't it better to have a const object to allow for > compiler optimizations? (I'm not a compiler guru, but I thought the > point of why we originally made the C++ handles be const was on the > argument for potential compiler optimizations) > > > On Jan 18, 2008, at 8:35 PM, Erez Haba wrote: > >> For example an implementation might choose to cache the error >> handler for MPI::COMM_WORD (in the MPI::Comm object) and call it >> itself on error so it can pass in the right object to the error >> handler. >> Thus requiring MPI::COMM_WORLD not to be const. >> >> >> -----Original Message----- >> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] >> On Behalf Of Jeff Squyres >> Sent: Friday, January 18, 2008 11:14 AM >> To: mpi-21_at_[hidden] >> Cc: mpi-21_at_[hidden] >> Subject: [mpi-21] const C++ MPI handles (take 2) >> >> On Jan 18, 2008, at 2:02 PM, Erez Haba wrote: >> >>> Okay; about one issue at a time. >> >> Changing mail subject to reflect the discussion... >> >>> *For this sentence* it does not matter what's a common usage for C++ >>> global variables. Some MPI implementations would need to have non- >>> const qualified global objects. >> >> Why? As I understand it, most (all?) MPI C++ implementations >> currently only require some objects to be non-const because of the >> standard-related issue that was already raised (Set_attr(), >> Set_name(), Set_errhandler() methods not having const variants). Is >> there a reason that an implementation would *need* MPI handles to be >> non-const? >> >> Per my prior mail, I believe that the standard should specify that >> some of the methods on these classes should have const and non-const >> variants, and then it should be fine to require that the predefined >> handles be const. >> >> So the question is still open: what's common practice in the C++ >> community regarding const/non-const global variable specification? >> This question will be moot if you can demonstrate that an >> implementation would need non-const C++ MPI predefined handles. >> >> -- >> Jeff Squyres >> Cisco Systems >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] const C++ MPI handles (take 2)
by unknown＠example.com 19 Jan '08

19 Jan '08

I agree, const is the better way to implement. The question is: do you want to *force* the optimized implementation? -----Original Message----- From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 18, 2008 5:49 PM To: mpi-21_at_[hidden] Cc: mpi-21_at_[hidden] Subject: Re: [mpi-21] const C++ MPI handles (take 2) Yes, that's the way the original C++ bindings were implemented. But it's not required or necessary to do that; that C errhandler could easily be cached somewhere else. More specifically, isn't it better to have a const object to allow for compiler optimizations? (I'm not a compiler guru, but I thought the point of why we originally made the C++ handles be const was on the argument for potential compiler optimizations) On Jan 18, 2008, at 8:35 PM, Erez Haba wrote: > For example an implementation might choose to cache the error > handler for MPI::COMM_WORD (in the MPI::Comm object) and call it > itself on error so it can pass in the right object to the error > handler. > Thus requiring MPI::COMM_WORLD not to be const. > > > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Friday, January 18, 2008 11:14 AM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: [mpi-21] const C++ MPI handles (take 2) > > On Jan 18, 2008, at 2:02 PM, Erez Haba wrote: > >> Okay; about one issue at a time. > > Changing mail subject to reflect the discussion... > >> *For this sentence* it does not matter what's a common usage for C++ >> global variables. Some MPI implementations would need to have non- >> const qualified global objects. > > Why? As I understand it, most (all?) MPI C++ implementations > currently only require some objects to be non-const because of the > standard-related issue that was already raised (Set_attr(), > Set_name(), Set_errhandler() methods not having const variants). Is > there a reason that an implementation would *need* MPI handles to be > non-const? > > Per my prior mail, I believe that the standard should specify that > some of the methods on these classes should have const and non-const > variants, and then it should be fine to require that the predefined > handles be const. > > So the question is still open: what's common practice in the C++ > community regarding const/non-const global variable specification? > This question will be moot if you can demonstrate that an > implementation would need non-const C++ MPI predefined handles. > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0