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

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

18 Jan '08

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

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

18 Jan '08

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

1 0

Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 18 Jan '08

18 Jan '08

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

1 0

const C++ MPI handles (take 2)
by unknown＠example.com 18 Jan '08

18 Jan '08

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

1 0

Re: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ handles
by unknown＠example.com 18 Jan '08

18 Jan '08

Okay; about one issue at a time. *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. For the specific definition (which seems to presented as a C++ comment in the standard) I agree, you want to know what to recommend. Thanks, .Erez -----Original Message----- From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 18, 2008 10:58 AM To: mpi-21_at_[hidden] Cc: mpi-21_at_[hidden] Subject: Re: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ handles On Jan 18, 2008, at 1:53 PM, Erez Haba wrote: > Aren't we also removing the const :) > The text would still be incorrect; in some implementations the > MPI::COMM_WORLD is not const qualified. > > I suggest removing this sentence. (In C++....) One issue at a time: this proposal is to remove "static" because it is clearly wrong. The "const" issue is different, and [much] more complicated. I am working on another proposal about the "const" issue in this sentence -- I still haven't heard back from you (or others) about what is common usage for C++ global variables (whether it is common to not specify whether they should be const or not). > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Friday, January 18, 2008 10:29 AM > To: mpi-21_at_[hidden]; mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ > handles > > This mail is a proposal for MPI 2.1, ballot 4. > > NOTE: This mail is a slight re-formatting of http://www.mpi-forum.org/mail_archive/mpi-21/2008/01/msg00119.html > to be in ballot proposal format. > > In MPI 2.0, page 9, lines 17-18 state: > > "MPI provides certain predefined opaque objects and predefined, static > handles to these objects. The user must not free such objects. In C+ > +, this is enforced by declaring the handles to these predefined > objects to be {\tt static const}." > > The "static" in the last sentence should be deleted. > > Rationale: > > When using namespaces, all the MPI symbols are in the namespace and > objects do not need to be static in a singleton object for the MPI > class. > > Specifically: they are static *only* if you are using the singleton > object for the MPI class. The context for the statement is talking > about the constant quality; the "static" is superfluous -- describing > whether "static" is necessary or not would be too much for this > section. > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] MPI 2.1 Abstract text
by unknown＠example.com 18 Jan '08

18 Jan '08

Doesn't it make is simpler for the reader if you explicitly use 1.3 rather than 1.2 or 1.1? less ambiguity. -----Original Message----- From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Friday, January 18, 2008 10:14 AM To: Mailing list for discussion of MPI 2.1 Cc: mpi-21_at_[hidden] Subject: Re: [mpi-21] MPI 2.1 Abstract text Erez, I used at the beginning MPI 1.1 and MPI-2 documents to reference the major documents that have been produced by MPI-1 and MPI-2 Forum. And I'm summarizing all other input in "and errata documents from the MPI Forum" (which are small compared to the work of MPI 1.1 and MPI-2). At the beginning, I'm intentionally not separate 1.2 and 2.0. I'm referencing the documents (i.e. "MPI 1.1 and MPI-2" and not "MPI 1.1 + 1.2 + 2.0") In the further parts of the abstract, I point to MPI 1.2 and MPI 1.3. Best regards Rolf On Fri, 18 Jan 2008 09:12:52 -0800 Erez Haba <erezh_at_[hidden]> wrote: >Shouldn't the first paragraph use the 1.3 version? (rather than 1.1 or 1.2) E.g., > >This document describes the MPI standard version 2.1 in one >combined document. This document combines the content from the >previous standards "MPI: A Message-Passing Interface Standard, ><date>" (MPI-1.3) and "MPI-2: Extensions to the >Message-Passing Interface, July, 1997" (MPI-1.3 and MPI-2.0) >and errata documents from the MPI Forum. > > >-----Original Message----- >From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Bronis R. de Supinski >Sent: Friday, January 18, 2008 7:52 AM >To: Mailing list for discussion of MPI 2.1 >Cc: mpi-21_at_[hidden] >Subject: Re: [mpi-21] MPI 2.1 Abstract text > > >Rolf: > >Re: >> This is the currently proposed Abstract for MPI 2.1: > >A couple minor editing suggestions: > >---------------------------------------------------------------------- >This document describes the MPI standard version 2.1 in one >combined document. This document combines the content from the >previous standards "MPI: A Message-Passing Interface Standard, >June 12, 1995" (MPI-1.1) and "MPI-2: Extensions to the >Message-Passing Interface, July, 1997" (MPI-1.2 and MPI-2.0) >and errata documents from the MPI Forum. >The standard MPI-1.1 includes point-to-point message passing, >collective communications, group and communicator concepts, >process topologies, environmental management, and a profiling >interface. Language bindings for C and Fortran are defined. >The MPI-1.2 chapter of the MPI-2 document contains clarifications >and corrections to the MPI-1.1 standard and defines MPI-1.2. >Together with corrections, these MPI-1 documents were combined >to MPI 1.3 (<data>, 2008) which was used as input for this document. >The second input is the MPI-2 part of the MPI-2 document, which >describes additions to the MPI-1 standard and defines the >MPI standard version 2.0. These include miscellaneous topics, >process creation and management, one-sided communications, >extended collective operations, external interfaces, I/O, >and additional language bindings (C++). Additional clarifications >and errata corrections to MPI-2.0 are also included. >---------------------------------------------------------------------- > >I changed "book" to "document" for consistency, and added a >"The " and a comma needed for grammatical correctness. > >Bronis > >> It is based on the abstract of MPI 2.0. >> MPI 1.1 hadn't any abstract. >> >> This abstact should tell the main features of MPI. >> It should not give a full history. This is done by the versions page. >> Hints from the MPI Forum meeting Jan. 2008 are also included, >> i.e., the major sources are referenced, but also the steps >> between, i.e., the clarifications and MPI 1.3. >> >> -------------------------------------------------------- >> 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) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> > > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 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] Ballot 4 proposal: "static" predefined MPI C++ handles
by unknown＠example.com 18 Jan '08

18 Jan '08

On Jan 18, 2008, at 1:53 PM, Erez Haba wrote: > Aren't we also removing the const :) > The text would still be incorrect; in some implementations the > MPI::COMM_WORLD is not const qualified. > > I suggest removing this sentence. (In C++....) One issue at a time: this proposal is to remove "static" because it is clearly wrong. The "const" issue is different, and [much] more complicated. I am working on another proposal about the "const" issue in this sentence -- I still haven't heard back from you (or others) about what is common usage for C++ global variables (whether it is common to not specify whether they should be const or not). > -----Original Message----- > From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] > On Behalf Of Jeff Squyres > Sent: Friday, January 18, 2008 10:29 AM > To: mpi-21_at_[hidden]; mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ > handles > > This mail is a proposal for MPI 2.1, ballot 4. > > NOTE: This mail is a slight re-formatting of http://www.mpi-forum.org/mail_archive/mpi-21/2008/01/msg00119.html > to be in ballot proposal format. > > In MPI 2.0, page 9, lines 17-18 state: > > "MPI provides certain predefined opaque objects and predefined, static > handles to these objects. The user must not free such objects. In C+ > +, this is enforced by declaring the handles to these predefined > objects to be {\tt static const}." > > The "static" in the last sentence should be deleted. > > Rationale: > > When using namespaces, all the MPI symbols are in the namespace and > objects do not need to be static in a singleton object for the MPI > class. > > Specifically: they are static *only* if you are using the singleton > object for the MPI class. The context for the statement is talking > about the constant quality; the "static" is superfluous -- describing > whether "static" is necessary or not would be too much for this > section. > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ handles
by unknown＠example.com 18 Jan '08

18 Jan '08

Aren't we also removing the const :) The text would still be incorrect; in some implementations the MPI::COMM_WORLD is not const qualified. I suggest removing this sentence. (In C++....) -----Original Message----- From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 18, 2008 10:29 AM To: mpi-21_at_[hidden]; mpi-21_at_[hidden] Subject: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++ handles This mail is a proposal for MPI 2.1, ballot 4. NOTE: This mail is a slight re-formatting of http://www.mpi-forum.org/mail_archive/mpi-21/2008/01/msg00119.html to be in ballot proposal format. In MPI 2.0, page 9, lines 17-18 state: "MPI provides certain predefined opaque objects and predefined, static handles to these objects. The user must not free such objects. In C+ +, this is enforced by declaring the handles to these predefined objects to be {\tt static const}." The "static" in the last sentence should be deleted. Rationale: When using namespaces, all the MPI symbols are in the namespace and objects do not need to be static in a singleton object for the MPI class. Specifically: they are static *only* if you are using the singleton object for the MPI class. The context for the statement is talking about the constant quality; the "static" is superfluous -- describing whether "static" is necessary or not would be too much for this section. -- Jeff Squyres Cisco Systems

1 0

Withdraw errata request
by unknown＠example.com 18 Jan '08

18 Jan '08

Per http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ , I withdraw my initial query about "MPI_FINALIZE in MPI-2 (with spawn)" (mail discussing: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus…) . There is no problem; there is no need for clarification. Let's remove it from the list of outstanding issues. -- Jeff Squyres Cisco Systems

1 0

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

18 Jan '08

This mail is a proposal for MPI 2.1, ballot 4. NOTE: This mail is a slight re-formatting of http://www.mpi-forum.org/mail_archive/mpi-21/2008/01/msg00119.html to be in ballot proposal format. In MPI 2.0, page 9, lines 17-18 state: "MPI provides certain predefined opaque objects and predefined, static handles to these objects. The user must not free such objects. In C+ +, this is enforced by declaring the handles to these predefined objects to be {\tt static const}." The "static" in the last sentence should be deleted. Rationale: When using namespaces, all the MPI symbols are in the namespace and objects do not need to be static in a singleton object for the MPI class. Specifically: they are static *only* if you are using the singleton object for the MPI class. The context for the statement is talking about the constant quality; the "static" is superfluous -- describing whether "static" is necessary or not would be too much for this section. -- Jeff Squyres Cisco Systems

1 0