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

Re: [mpi-21] topo mpi (was Re: Ballot 4 - 0-dim MPI_CART_CREATE and MP I_CART_SUB)
by unknown＠example.com 24 Jan '08

24 Jan '08

William, yes, I reported the bahavior of 5 different MPI existing MPI implementations. And I attached my test program that calls the MPI topology functions and reports the behavior of the MPI library to which it is compiled and linked. Using this test program, everybody can detect that different MPI implementations are giving quite different answers and therefore, there is a need for clarifying the MPI 1.1 standard. Best regards Rolf On Thu, 24 Jan 2008 05:02:47 +0800 "William Yu" <wyu_at_[hidden]> wrote: >Hi Rolf, > >Just curious. Is this implemented already? Sounds like you have a reference implementation built against different MPIs. > >Thanks. > >________________ Reply Header ________________ >Subject: [mpi-21] Ballot 4 - 0-dim MPI_CART_CREATE and MPI_CART_SUB >Author: "Rolf Rabenseifner" <rabenseifner_at_[hidden]> >Date: January 23rd 2008 5:44 pm > >This is a discussion-point for MPI 2.1, Ballot 4. > >This is a follow up to: > Questions about Graph_create, Cart_crate, and Cart_coords > 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… > >I'm starting a new 2nd stream for the zero-dim discussion. >------------------------------- > >This report shows significant differences of MPI implementations >in the (extreme) case of zero-dimensional topologies! > >Therefore clarifications may be necessary. >(Although hopefully never an application may produce >zero-dimensional Cartesian topologies!) > >If there are no objections, I would produce clarifications >for MPI-2.1 according to the behavior of mpich2 >and MPI from IBM (except the rank -767705708, see below). > >MPI-1.1 Sect. 6.5.6, page 187, routine MPI_CART_SUB defines >on lines 38-42: > If a cartesian topology has been created with MPI_CART_CREATE, > the function MPI_CART_SUB can be used to partition the > communicator group into subgroups that form lower-dimensional > cartesian subgrids, and to build for each subgroup a > communicator with the associated subgrid cartesian topology. > (This function is closely related to MPI_COMM_SPLIT.) > >The text clearly says, that the new communicator must >(1) have a Cartesian topology associated >(2) be lower-dimensional in the case of a subgrid > >There is no restriction on the input array remain_dims. >Therefore all MPI implementations (that I tested) >allow that all entries in remain_dims are "false". > >I tested several MPI libraries with creating a subgrid >with MPI_Cart_sub(remain_dims=0) from a 1-dim Cartesian >topology. >I tested the subgrid communicator with MPI_Topo_test. >In the case of MPI_CART, I used MPI_Cartdim_get to retrieve >ndims, and MPI_Cart_get for further details: > >- mpich2: MPI_CART, ndims=0, > 1.0.3 MPI_Cart_get works, > but keeps all OUT arguments unchanged > >- IBM: MPI_CART, ndims=0, > (on SP) MPI_Cart_get works, > but keeps all OUT arguments unchanged > >- OpenMPI: MPI_CART, ndims=1, > 1.2.4 MPI_Cart_get works > and returns dims=1, periods=0, coords=0 independent > from process or periods in the original comm. > (may be wrong because (2) is not fulfilled) > >- NEC MP/EX: not MPI_CART > (may be wrong because (1) is not fulfilled) > >- Voltaire: not MPI_CART > (mpich1) (may be wrong because (1) is not fulfilled) > >With the implementations that return a correct zero-dim Cartesian >topology, I tested further usage of this zero-dim communicator: > >- MPI_Comm_size returns 1 and MPI_Comm_rank returns 0 because > this communicator is like MPI_COMM_SELF, but with Cartesian > topology associated. > >- MPI_Cart_rank(IN ZeroDimComm, IN coords=0, OUT rank) > Rationale. A zero-dim communicator has zero coords, > i.e., this routine should not examine the coords > input argument. > --> mpich2: rank = 0 is returned > (may be because this is the only existing rank > in this communicator, this value may make sense, > independent of the coord, that should not be > analyzed) > --> IBM: rank = -767705708 is returned > (strange value, not MPI_PROC_NULL, not MPI_UNDEFINED) > >- MPI_Cart_coords(IN ZeroDimComm, IN rank=0, OUT coords) > Rationale. A zero-dim communicator has zero coords, > i.e., this routine should not return anything > in the coords output argument. > --> mpich2 and IBM: coords is not modified (as expected) > >- MPI_Cart_sub(IN ZeroDimComm, IN remain_dims=0, OUT subsubcomm) > Rationale. A zero-dim communicator has zero dimensions, > i.e., this routine should not examine remain_dims > and the returned communicator should be again > a zero-dim Cartesian communicator. > --> mpich2 and IBM: subsubcomm is a zero-dim Cartesian > communicator (as expected) > >- MPI_Cart_shift(IN ZeroDimComm, IN direction=0, IN disp=1, > OUT src, OUT dest) > Rationale. This call is erroneous because in a zero-dim > communicator, the direction=0 does not exist. > mpich2 and IBM: They detect the error and abort. > >(In OpenMPI, all these calls work as expected on a > 1-dimensional topology on a "MPI_COMM_SELF") > >The last test is not addressed by MPI-1.1: >Is it possible to build a zero-dim Cartesian topology >directly by calling MPI_Cart_create: > > MPI_Cart_create(IN MPI_COMM_SELF, IN ndims=0, IN dims=1, > IN Periods, IN reorder, OUT ZeroDimComm) > >Results: All tested MPI implementations return an error > and abort. > (Same on MPI_COMM_WORLD) > >The latter question was raised by Jesper Traeff. > >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

topo mpi (was Re: Ballot 4 - 0-dim MPI_CART_CREATE and MP I_CART_SUB)
by unknown＠example.com 23 Jan '08

23 Jan '08

Hi Rolf, Just curious. Is this implemented already? Sounds like you have a reference implementation built against different MPIs. Thanks. ________________ Reply Header ________________ Subject: [mpi-21] Ballot 4 - 0-dim MPI_CART_CREATE and MPI_CART_SUB Author: "Rolf Rabenseifner" <rabenseifner_at_[hidden]> Date: January 23rd 2008 5:44 pm This is a discussion-point for MPI 2.1, Ballot 4. This is a follow up to: Questions about Graph_create, Cart_crate, and Cart_coords 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… I'm starting a new 2nd stream for the zero-dim discussion. ------------------------------- This report shows significant differences of MPI implementations in the (extreme) case of zero-dimensional topologies! Therefore clarifications may be necessary. (Although hopefully never an application may produce zero-dimensional Cartesian topologies!) If there are no objections, I would produce clarifications for MPI-2.1 according to the behavior of mpich2 and MPI from IBM (except the rank -767705708, see below). MPI-1.1 Sect. 6.5.6, page 187, routine MPI_CART_SUB defines on lines 38-42: If a cartesian topology has been created with MPI_CART_CREATE, the function MPI_CART_SUB can be used to partition the communicator group into subgroups that form lower-dimensional cartesian subgrids, and to build for each subgroup a communicator with the associated subgrid cartesian topology. (This function is closely related to MPI_COMM_SPLIT.) The text clearly says, that the new communicator must (1) have a Cartesian topology associated (2) be lower-dimensional in the case of a subgrid There is no restriction on the input array remain_dims. Therefore all MPI implementations (that I tested) allow that all entries in remain_dims are "false". I tested several MPI libraries with creating a subgrid with MPI_Cart_sub(remain_dims=0) from a 1-dim Cartesian topology. I tested the subgrid communicator with MPI_Topo_test. In the case of MPI_CART, I used MPI_Cartdim_get to retrieve ndims, and MPI_Cart_get for further details: - mpich2: MPI_CART, ndims=0, 1.0.3 MPI_Cart_get works, but keeps all OUT arguments unchanged - IBM: MPI_CART, ndims=0, (on SP) MPI_Cart_get works, but keeps all OUT arguments unchanged - OpenMPI: MPI_CART, ndims=1, 1.2.4 MPI_Cart_get works and returns dims=1, periods=0, coords=0 independent from process or periods in the original comm. (may be wrong because (2) is not fulfilled) - NEC MP/EX: not MPI_CART (may be wrong because (1) is not fulfilled) - Voltaire: not MPI_CART (mpich1) (may be wrong because (1) is not fulfilled) With the implementations that return a correct zero-dim Cartesian topology, I tested further usage of this zero-dim communicator: - MPI_Comm_size returns 1 and MPI_Comm_rank returns 0 because this communicator is like MPI_COMM_SELF, but with Cartesian topology associated. - MPI_Cart_rank(IN ZeroDimComm, IN coords=0, OUT rank) Rationale. A zero-dim communicator has zero coords, i.e., this routine should not examine the coords input argument. --> mpich2: rank = 0 is returned (may be because this is the only existing rank in this communicator, this value may make sense, independent of the coord, that should not be analyzed) --> IBM: rank = -767705708 is returned (strange value, not MPI_PROC_NULL, not MPI_UNDEFINED) - MPI_Cart_coords(IN ZeroDimComm, IN rank=0, OUT coords) Rationale. A zero-dim communicator has zero coords, i.e., this routine should not return anything in the coords output argument. --> mpich2 and IBM: coords is not modified (as expected) - MPI_Cart_sub(IN ZeroDimComm, IN remain_dims=0, OUT subsubcomm) Rationale. A zero-dim communicator has zero dimensions, i.e., this routine should not examine remain_dims and the returned communicator should be again a zero-dim Cartesian communicator. --> mpich2 and IBM: subsubcomm is a zero-dim Cartesian communicator (as expected) - MPI_Cart_shift(IN ZeroDimComm, IN direction=0, IN disp=1, OUT src, OUT dest) Rationale. This call is erroneous because in a zero-dim communicator, the direction=0 does not exist. mpich2 and IBM: They detect the error and abort. (In OpenMPI, all these calls work as expected on a 1-dimensional topology on a "MPI_COMM_SELF") The last test is not addressed by MPI-1.1: Is it possible to build a zero-dim Cartesian topology directly by calling MPI_Cart_create: MPI_Cart_create(IN MPI_COMM_SELF, IN ndims=0, IN dims=1, IN Periods, IN reorder, OUT ZeroDimComm) Results: All tested MPI implementations return an error and abort. (Same on MPI_COMM_WORLD) The latter question was raised by Jesper Traeff. 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

1 0

Ballot 4 - 0-dim MPI_CART_CREATE and MPI_CART_SUB
by unknown＠example.com 23 Jan '08

23 Jan '08

This is a discussion-point for MPI 2.1, Ballot 4. This is a follow up to: Questions about Graph_create, Cart_crate, and Cart_coords 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… I'm starting a new 2nd stream for the zero-dim discussion. ------------------------------- This report shows significant differences of MPI implementations in the (extreme) case of zero-dimensional topologies! Therefore clarifications may be necessary. (Although hopefully never an application may produce zero-dimensional Cartesian topologies!) If there are no objections, I would produce clarifications for MPI-2.1 according to the behavior of mpich2 and MPI from IBM (except the rank -767705708, see below). MPI-1.1 Sect. 6.5.6, page 187, routine MPI_CART_SUB defines on lines 38-42: If a cartesian topology has been created with MPI_CART_CREATE, the function MPI_CART_SUB can be used to partition the communicator group into subgroups that form lower-dimensional cartesian subgrids, and to build for each subgroup a communicator with the associated subgrid cartesian topology. (This function is closely related to MPI_COMM_SPLIT.) The text clearly says, that the new communicator must (1) have a Cartesian topology associated (2) be lower-dimensional in the case of a subgrid There is no restriction on the input array remain_dims. Therefore all MPI implementations (that I tested) allow that all entries in remain_dims are "false". I tested several MPI libraries with creating a subgrid with MPI_Cart_sub(remain_dims=0) from a 1-dim Cartesian topology. I tested the subgrid communicator with MPI_Topo_test. In the case of MPI_CART, I used MPI_Cartdim_get to retrieve ndims, and MPI_Cart_get for further details: - mpich2: MPI_CART, ndims=0, 1.0.3 MPI_Cart_get works, but keeps all OUT arguments unchanged - IBM: MPI_CART, ndims=0, (on SP) MPI_Cart_get works, but keeps all OUT arguments unchanged - OpenMPI: MPI_CART, ndims=1, 1.2.4 MPI_Cart_get works and returns dims=1, periods=0, coords=0 independent from process or periods in the original comm. (may be wrong because (2) is not fulfilled) - NEC MP/EX: not MPI_CART (may be wrong because (1) is not fulfilled) - Voltaire: not MPI_CART (mpich1) (may be wrong because (1) is not fulfilled) With the implementations that return a correct zero-dim Cartesian topology, I tested further usage of this zero-dim communicator: - MPI_Comm_size returns 1 and MPI_Comm_rank returns 0 because this communicator is like MPI_COMM_SELF, but with Cartesian topology associated. - MPI_Cart_rank(IN ZeroDimComm, IN coords=0, OUT rank) Rationale. A zero-dim communicator has zero coords, i.e., this routine should not examine the coords input argument. --> mpich2: rank = 0 is returned (may be because this is the only existing rank in this communicator, this value may make sense, independent of the coord, that should not be analyzed) --> IBM: rank = -767705708 is returned (strange value, not MPI_PROC_NULL, not MPI_UNDEFINED) - MPI_Cart_coords(IN ZeroDimComm, IN rank=0, OUT coords) Rationale. A zero-dim communicator has zero coords, i.e., this routine should not return anything in the coords output argument. --> mpich2 and IBM: coords is not modified (as expected) - MPI_Cart_sub(IN ZeroDimComm, IN remain_dims=0, OUT subsubcomm) Rationale. A zero-dim communicator has zero dimensions, i.e., this routine should not examine remain_dims and the returned communicator should be again a zero-dim Cartesian communicator. --> mpich2 and IBM: subsubcomm is a zero-dim Cartesian communicator (as expected) - MPI_Cart_shift(IN ZeroDimComm, IN direction=0, IN disp=1, OUT src, OUT dest) Rationale. This call is erroneous because in a zero-dim communicator, the direction=0 does not exist. mpich2 and IBM: They detect the error and abort. (In OpenMPI, all these calls work as expected on a 1-dimensional topology on a "MPI_COMM_SELF") The last test is not addressed by MPI-1.1: Is it possible to build a zero-dim Cartesian topology directly by calling MPI_Cart_create: MPI_Cart_create(IN MPI_COMM_SELF, IN ndims=0, IN dims=1, IN Periods, IN reorder, OUT ZeroDimComm) Results: All tested MPI implementations return an error and abort. (Same on MPI_COMM_WORLD) The latter question was raised by Jesper Traeff. 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] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 23 Jan '08

23 Jan '08

On Jan 23, 2008, at 7:16 AM, Jeff Squyres wrote: > This would be in accordance with the existing MPI-1:2.2 language, > and therefore (I think) redundant. > > However, see my summary e-mail from last night about the C++ > bindings -- I am wondering why the special case for [IN]OUT handle > arguments exists to begin with (that a parameter is OUT if the > underlying MPI object is changed when the handle is not). I just now saw your other mail about all of MPI-1:2 being deprecated in favor of MPI-2:2 -- you're right; I followed up in that thread. > > > > On Jan 22, 2008, at 11:29 AM, Rolf Rabenseifner wrote: > >> An alternative-proposal would be to add a clarifying sentence in >> Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: >> Handle arguments can be marked at INOUT to indicate that the handle >> itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), >> or to indicate that the object referenced by the handle may be >> changed but the handle itself is kept unchanged >> (e.g., MPI_TYPE_SET_NAME). >> >> Rolf Rabenseifner >> >> >> On Mon, 21 Jan 2008 09:42:02 -0500 >> Jeff Squyres <jsquyres_at_[hidden]> wrote: >>> 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 >>> >> >> >> >> 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) >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 23 Jan '08

23 Jan '08

On Jan 23, 2008, at 4:33 AM, Rolf Rabenseifner wrote: > you are referencing to MPI-1.1, Sect. 2.2. > The full Chapter 2 of MPI-1.1 is deprecated and substituted by > the full Chapter 2 of MPI-2.0. > In the substituting MPI-2.0 Sect. 2.3, there exist the > following new paragraph: > "MPIs use of IN, OUT and INOUT is intended to indicate to the user > how an argument is to be used, but does not provide a rigorous > classification that can be translated directly into all language > bindings (e.g., INTENT in Fortran 90 bindings or const in C > bindings). > For instance, the constant MPI BOTTOM can usually be passed to OUT > buffer arguments. Similarly, MPI STATUS IGNORE can be passed as the > OUT status argument." Ok; I missed that text -- thanks. So replace every instance of "MPI-1:2.2" in my original text with "MPI-2:2.3", where exactly the same special case definition exists. > My comments and alternative-proposal from Tue, 22 Jan 2008 17:29:51 > was about this paragraph (updated text to reflect also the "IN" of > "INOUT"): > >> An alternative-proposal would be to add a clarifying sentence in >> Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: >> Handle arguments can be marked at INOUT to indicate that the handle >> itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), >> or to indicate that the object referenced by the handle > already exists and >> may be changed but the handle itself is kept unchanged >> (e.g., MPI_TYPE_SET_NAME). Per the text in my summary mail (below), I think that that would be exactly the wrong thing to say (and it would be redundant with MPI-2:2.3). My point is that this special case definition for [IN]OUT should go away if no one can specify the reason why it's there. Indeed, the text that Rolf cites in MPI-2:2.3 both strengthens and weakens my arguments: - STRENGTHEN: "MPI's use of IN, OUT and INOUT is intended to indicate to the user how an argument is to be used..." - WEAKEN: "...but does not provide a rigorous classification that can be translated directly into all language bindings (e.g., INTENT in Fortran 90 bindings or const in C++ bindings)." However, the latter part of the sentence can be ignored because it says that IN/OUT/INOUT do not *have* to be used as a rigorous classification. This clears the way for the 3 proposals that I sent the other day: 1. Make all the SET_NAME and SET_ERRHANDLER functions have IN MPI handle arguments (vs. INOUT) -- by the new sentence in MPI-2:2.3, the value of the argument is not being changed by the function call (per the already-existing C bindings). So these are now clearly IN arguments. Also, make the C++ bindings for these functions be const. 2. Restore the "const" to the C++ MPI predefined handles that were removed in ballot 2. 3. Make MPI::COMM_WORLD and MPI::COMM_SELF be const. Additionally, I would like to request/motion/whatever that the "remove const from more C++ constants" item be withdrawn from what was supposed to be on ballot 3 but got moved to ballot 4. *** The end goal is to make all the MPI C++ constants be "const" (except MPI::BOTTOM, as we discussed in Chicago) and have all the SET_NAME and SET_ERRHANDLER methods be const. Thanks. - Jeff > Best regards > Rolf > > > On Tue, 22 Jan 2008 20:07:05 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> The 3 proposals that I sent about C++ issues are both intertwined and >> represent a very complex set of issues. >> >> Shorter version >> =============== >> >> Does anyone know/remember why the "special case" for the definition >> of >> OUT parameters exists in MPI-1:2.2? >> >> I ask because the C++ bindings were modeled off the IN/OUT/INOUT >> designations of the language neutral bindings. MPI_COMM_SET_NAME >> (and >> others) use the "special case" definition of the [IN]OUT designation >> for the MPI communicator handle parameter. Two facts indicate that >> we >> should either override this INOUT designation for the C++ binding >> (and >> therefore make the method const) and/or revisit the "special case" >> language in MPI-1:2.2: >> >> 1. The C binding does not allow the implementation to change the >> handle value >> 2. The following is a valid MPI code: >> >> MPI::Intracomm cxx_comm = MPI::COMM_WORLD; >> cxx_comm.Set_name("foo"); >> MPI::COMM_WORLD.Get_name(name, len); >> cout << name << endl; >> >> The output will be "foo" even though we set the name on cxx_comm >> and retrieved it from MPI::COMM_WORLD ***because the state changed on >> the underlying MPI object, not the upper-level handles*** (the same >> is >> true for error handlers). >> >> Hence, the Set_name() method should be const because the MPI handle >> will not (and cannot) change. Similar arguments apply to keeping the >> MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their >> values >> must never change during execution. It then follows that unless >> there >> is a good reason for the "special case" language in MPI-1:2.2, it >> should be removed. >> >> Longer version / more details >> ============================= >> >> At the heart of the issue seems to be text from MPI-1:2.2 about the >> definition of IN, OUT, and INOUT parameters to MPI functions. This >> text was used to guide many of the decisions about the C++ bindings, >> such as the const-ness (or not) of C++ methods and MPI predefined C++ >> handles. The text states: >> >> ----- >> * the call uses but does not update an argument marked IN >> * the call may update an argument marked OUT >> * the call both uses and updates an argument marked INOUT >> >> There is one special case -- if an argument is a handle to an opaque >> object (these terms are defined in Section 2.4.1) and the object is >> updated by the procedure call, then the argument is marked OUT. It >> is >> marked this way even though the handle itself is not modified -- we >> use the OUT attribute to denote that what the handle _references_ is >> updated. >> ----- >> >> The special case for the OUT definition is important because the C++ >> bindings were created to mimic the IN, OUT, and INOUT behavior in a >> language that is stricter than C and Fortran: C++ will fail to >> compile >> if an application violates the defined semantics (which is a good >> thing). >> >> *** The big question: does anyone know/remember why this special case >> *** for the "OUT" definition exists? >> >> The special case seems to imply that *explicit* changes to MPI >> objects >> should be marked as an [IN]OUT parameter (e.g., SET_NAME and >> SET_ERRHANDLER). Apparently, *implicit* changes to the underlying >> MPI >> object (such as MPI_ISEND) do not count / should be IN (i.e., many >> MPI >> implementation *do* change the state either on the communicator or >> something related to the communicator when a send or receive is >> initiated, even though the communicator is an IN argument). >> >> But remember that MPI clearly states that the handle is separate from >> the underlying MPI object. So why does the binding care if the back- >> end object is updated? (regardless of whether the change to the >> object is explicit or implicit) >> >> For example, the language-neutral binding for MPI_COMM_SET_NAME has >> the communicator as an INOUT argument. This clearly falls within the >> "special case" definition because the function semantics explicitly >> change state on the underlying MPI object. >> >> But note that the C binding is "int MPI_Comm_set_name(MPI_Comm >> comm, ...)". Notice that the comm is passed by value, not by >> reference. So even though the language neutral binding called that >> parameter INOUT, it's not possible for the MPI implementation to >> change the value of the handle. >> >> My claim is that if we want to ensure that the C++ bindings match the >> C bindings (i.e., that the implementation cannot change the value of >> the MPI handle), then the method should be const (i.e., >> cxx_comm.Set_name(...)) *because the handle value will not, and >> ***cannot***, change*. >> >> Simply put: regardless of language or implementation, MPI handles >> must >> have true handle semantics. For example: >> >> MPI::Intracomm cxx_comm = MPI::COMM_WORLD; >> cxx_comm.Set_name("C++ r00l3z!"); >> >> MPI::COMM_WORLD.Get_name(name, len); >> cout << name << endl; >> >> The above will output "C++ r00l3z!" because cxx_comm and >> MPI::COMM_WORLD are handles referring to the same underlying >> communicator. Hence, the only state that the handles have is >> whatever >> refers to their back-end MPI object. Having Set_name() be const >> keeps the *handle* const, not the underlying MPI object. >> >> Tying this all together: >> >> 1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle >> because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must >> return >> the same results (the same is true for error handlers). Hence, >> regardless of the implementation of the C++ bindings, the handle >> value >> cannot change. Therefore, this method (and all the others like it) >> should be const. >> >> 2. As a related issue, if no one can remember why the "special case" >> exists for OUT, then I think we should remove this text and then >> change all those INOUT parameters for the functions I cited in my >> earlier proposal to IN. This would make the C++ bindings consistent >> with the IN/OUT/INOUT specifications of the language-neutral >> bindings. >> >> 3. All the MPI C++ predefined handles should be const for many of the >> same reasons. Regardless of what happens to the underlying MPI >> object, the value of the handle cannot ever change. This is >> guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: >> >> "All named constants, with the exceptions noted below for Fortran, >> can >> be used in initialization expressions or assignments. These >> constants >> do not change values during execution. Opaque objects accessed by >> constant handles are defined and do not change value between MPI >> initialization MPI_INIT and MPI completion MPI_FINALIZE." >> >> Hence, they should all be "const". >> >> ----- >> >> In short: C++ gives us stronger protections to ensure that >> applications don't shoot themselves in the foot. If the MPI >> predefined handles are const, then statements like "MPI::INT = >> my_dtype;" will fail to compile. This is a Good Thing. >> >> The original C++ bindings tried to take advantage of const, but >> missed >> a few points. Ballot two and one of the items in ballot 3 >> incorrectly >> tried to fix these points by removing const in several places. That >> "fixes" the problem, but removes many of the good qualities that we >> can get in C++ with "const". So let's fix the real problem and leave >> "const" in the C++ bindings. >> >> Are you confused yet? :-) >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> 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) > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 23 Jan '08

23 Jan '08

This would be in accordance with the existing MPI-1:2.2 language, and therefore (I think) redundant. However, see my summary e-mail from last night about the C++ bindings -- I am wondering why the special case for [IN]OUT handle arguments exists to begin with (that a parameter is OUT if the underlying MPI object is changed when the handle is not). On Jan 22, 2008, at 11:29 AM, Rolf Rabenseifner wrote: > An alternative-proposal would be to add a clarifying sentence in > Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: > Handle arguments can be marked at INOUT to indicate that the handle > itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), > or to indicate that the object referenced by the handle may be > changed but the handle itself is kept unchanged > (e.g., MPI_TYPE_SET_NAME). > > Rolf Rabenseifner > > > On Mon, 21 Jan 2008 09:42:02 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> 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 >> > > > > 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) > -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 23 Jan '08

23 Jan '08

Jeff, you are referencing to MPI-1.1, Sect. 2.2. The full Chapter 2 of MPI-1.1 is deprecated and substituted by the full Chapter 2 of MPI-2.0. In the substituting MPI-2.0 Sect. 2.3, there exist the following new paragraph: "MPIs use of IN, OUT and INOUT is intended to indicate to the user how an argument is to be used, but does not provide a rigorous classification that can be translated directly into all language bindings (e.g., INTENT in Fortran 90 bindings or const in C bindings). For instance, the constant MPI BOTTOM can usually be passed to OUT buffer arguments. Similarly, MPI STATUS IGNORE can be passed as the OUT status argument." My comments and alternative-proposal from Tue, 22 Jan 2008 17:29:51 was about this paragraph (updated text to reflect also the "IN" of "INOUT"): >An alternative-proposal would be to add a clarifying sentence in >Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: > Handle arguments can be marked at INOUT to indicate that the handle > itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), > or to indicate that the object referenced by the handle already exists and > may be changed but the handle itself is kept unchanged > (e.g., MPI_TYPE_SET_NAME). Best regards Rolf On Tue, 22 Jan 2008 20:07:05 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >The 3 proposals that I sent about C++ issues are both intertwined and >represent a very complex set of issues. > >Shorter version >=============== > >Does anyone know/remember why the "special case" for the definition of >OUT parameters exists in MPI-1:2.2? > >I ask because the C++ bindings were modeled off the IN/OUT/INOUT >designations of the language neutral bindings. MPI_COMM_SET_NAME (and >others) use the "special case" definition of the [IN]OUT designation >for the MPI communicator handle parameter. Two facts indicate that we >should either override this INOUT designation for the C++ binding (and >therefore make the method const) and/or revisit the "special case" >language in MPI-1:2.2: > >1. The C binding does not allow the implementation to change the >handle value >2. The following is a valid MPI code: > > MPI::Intracomm cxx_comm = MPI::COMM_WORLD; > cxx_comm.Set_name("foo"); > MPI::COMM_WORLD.Get_name(name, len); > cout << name << endl; > > The output will be "foo" even though we set the name on cxx_comm >and retrieved it from MPI::COMM_WORLD ***because the state changed on >the underlying MPI object, not the upper-level handles*** (the same is >true for error handlers). > >Hence, the Set_name() method should be const because the MPI handle >will not (and cannot) change. Similar arguments apply to keeping the >MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their values >must never change during execution. It then follows that unless there >is a good reason for the "special case" language in MPI-1:2.2, it >should be removed. > >Longer version / more details >============================= > >At the heart of the issue seems to be text from MPI-1:2.2 about the >definition of IN, OUT, and INOUT parameters to MPI functions. This >text was used to guide many of the decisions about the C++ bindings, >such as the const-ness (or not) of C++ methods and MPI predefined C++ >handles. The text states: > >----- > * the call uses but does not update an argument marked IN > * the call may update an argument marked OUT > * the call both uses and updates an argument marked INOUT > >There is one special case -- if an argument is a handle to an opaque >object (these terms are defined in Section 2.4.1) and the object is >updated by the procedure call, then the argument is marked OUT. It is >marked this way even though the handle itself is not modified -- we >use the OUT attribute to denote that what the handle _references_ is >updated. >----- > >The special case for the OUT definition is important because the C++ >bindings were created to mimic the IN, OUT, and INOUT behavior in a >language that is stricter than C and Fortran: C++ will fail to compile >if an application violates the defined semantics (which is a good >thing). > >*** The big question: does anyone know/remember why this special case >*** for the "OUT" definition exists? > >The special case seems to imply that *explicit* changes to MPI objects >should be marked as an [IN]OUT parameter (e.g., SET_NAME and >SET_ERRHANDLER). Apparently, *implicit* changes to the underlying MPI >object (such as MPI_ISEND) do not count / should be IN (i.e., many MPI >implementation *do* change the state either on the communicator or >something related to the communicator when a send or receive is >initiated, even though the communicator is an IN argument). > >But remember that MPI clearly states that the handle is separate from >the underlying MPI object. So why does the binding care if the back- >end object is updated? (regardless of whether the change to the >object is explicit or implicit) > >For example, the language-neutral binding for MPI_COMM_SET_NAME has >the communicator as an INOUT argument. This clearly falls within the >"special case" definition because the function semantics explicitly >change state on the underlying MPI object. > >But note that the C binding is "int MPI_Comm_set_name(MPI_Comm >comm, ...)". Notice that the comm is passed by value, not by >reference. So even though the language neutral binding called that >parameter INOUT, it's not possible for the MPI implementation to >change the value of the handle. > >My claim is that if we want to ensure that the C++ bindings match the >C bindings (i.e., that the implementation cannot change the value of >the MPI handle), then the method should be const (i.e., >cxx_comm.Set_name(...)) *because the handle value will not, and >***cannot***, change*. > >Simply put: regardless of language or implementation, MPI handles must >have true handle semantics. For example: > > MPI::Intracomm cxx_comm = MPI::COMM_WORLD; > cxx_comm.Set_name("C++ r00l3z!"); > > MPI::COMM_WORLD.Get_name(name, len); > cout << name << endl; > >The above will output "C++ r00l3z!" because cxx_comm and >MPI::COMM_WORLD are handles referring to the same underlying >communicator. Hence, the only state that the handles have is whatever >refers to their back-end MPI object. Having Set_name() be const >keeps the *handle* const, not the underlying MPI object. > >Tying this all together: > >1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle >because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must return >the same results (the same is true for error handlers). Hence, >regardless of the implementation of the C++ bindings, the handle value >cannot change. Therefore, this method (and all the others like it) >should be const. > >2. As a related issue, if no one can remember why the "special case" >exists for OUT, then I think we should remove this text and then >change all those INOUT parameters for the functions I cited in my >earlier proposal to IN. This would make the C++ bindings consistent >with the IN/OUT/INOUT specifications of the language-neutral bindings. > >3. All the MPI C++ predefined handles should be const for many of the >same reasons. Regardless of what happens to the underlying MPI >object, the value of the handle cannot ever change. This is >guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: > >"All named constants, with the exceptions noted below for Fortran, can >be used in initialization expressions or assignments. These constants >do not change values during execution. Opaque objects accessed by >constant handles are defined and do not change value between MPI >initialization MPI_INIT and MPI completion MPI_FINALIZE." > >Hence, they should all be "const". > >----- > >In short: C++ gives us stronger protections to ensure that >applications don't shoot themselves in the foot. If the MPI >predefined handles are const, then statements like "MPI::INT = >my_dtype;" will fail to compile. This is a Good Thing. > >The original C++ bindings tried to take advantage of const, but missed >a few points. Ballot two and one of the items in ballot 3 incorrectly >tried to fix these points by removing const in several places. That >"fixes" the problem, but removes many of the good qualities that we >can get in C++ with "const". So let's fix the real problem and leave >"const" in the C++ bindings. > >Are you confused yet? :-) > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >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

C++ predefined MPI handles, const, IN/INOUT/OUT, etc.
by unknown＠example.com 22 Jan '08

22 Jan '08

The 3 proposals that I sent about C++ issues are both intertwined and represent a very complex set of issues. Shorter version =============== Does anyone know/remember why the "special case" for the definition of OUT parameters exists in MPI-1:2.2? I ask because the C++ bindings were modeled off the IN/OUT/INOUT designations of the language neutral bindings. MPI_COMM_SET_NAME (and others) use the "special case" definition of the [IN]OUT designation for the MPI communicator handle parameter. Two facts indicate that we should either override this INOUT designation for the C++ binding (and therefore make the method const) and/or revisit the "special case" language in MPI-1:2.2: 1. The C binding does not allow the implementation to change the handle value 2. The following is a valid MPI code: MPI::Intracomm cxx_comm = MPI::COMM_WORLD; cxx_comm.Set_name("foo"); MPI::COMM_WORLD.Get_name(name, len); cout << name << endl; The output will be "foo" even though we set the name on cxx_comm and retrieved it from MPI::COMM_WORLD ***because the state changed on the underlying MPI object, not the upper-level handles*** (the same is true for error handlers). Hence, the Set_name() method should be const because the MPI handle will not (and cannot) change. Similar arguments apply to keeping the MPI predefined C++ handles as "const" (MPI::INT, etc.) -- their values must never change during execution. It then follows that unless there is a good reason for the "special case" language in MPI-1:2.2, it should be removed. Longer version / more details ============================= At the heart of the issue seems to be text from MPI-1:2.2 about the definition of IN, OUT, and INOUT parameters to MPI functions. This text was used to guide many of the decisions about the C++ bindings, such as the const-ness (or not) of C++ methods and MPI predefined C++ handles. The text states: ----- * the call uses but does not update an argument marked IN * the call may update an argument marked OUT * the call both uses and updates an argument marked INOUT There is one special case -- if an argument is a handle to an opaque object (these terms are defined in Section 2.4.1) and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified -- we use the OUT attribute to denote that what the handle _references_ is updated. ----- The special case for the OUT definition is important because the C++ bindings were created to mimic the IN, OUT, and INOUT behavior in a language that is stricter than C and Fortran: C++ will fail to compile if an application violates the defined semantics (which is a good thing). *** The big question: does anyone know/remember why this special case *** for the "OUT" definition exists? The special case seems to imply that *explicit* changes to MPI objects should be marked as an [IN]OUT parameter (e.g., SET_NAME and SET_ERRHANDLER). Apparently, *implicit* changes to the underlying MPI object (such as MPI_ISEND) do not count / should be IN (i.e., many MPI implementation *do* change the state either on the communicator or something related to the communicator when a send or receive is initiated, even though the communicator is an IN argument). But remember that MPI clearly states that the handle is separate from the underlying MPI object. So why does the binding care if the back- end object is updated? (regardless of whether the change to the object is explicit or implicit) For example, the language-neutral binding for MPI_COMM_SET_NAME has the communicator as an INOUT argument. This clearly falls within the "special case" definition because the function semantics explicitly change state on the underlying MPI object. But note that the C binding is "int MPI_Comm_set_name(MPI_Comm comm, ...)". Notice that the comm is passed by value, not by reference. So even though the language neutral binding called that parameter INOUT, it's not possible for the MPI implementation to change the value of the handle. My claim is that if we want to ensure that the C++ bindings match the C bindings (i.e., that the implementation cannot change the value of the MPI handle), then the method should be const (i.e., cxx_comm.Set_name(...)) *because the handle value will not, and ***cannot***, change*. Simply put: regardless of language or implementation, MPI handles must have true handle semantics. For example: MPI::Intracomm cxx_comm = MPI::COMM_WORLD; cxx_comm.Set_name("C++ r00l3z!"); MPI::COMM_WORLD.Get_name(name, len); cout << name << endl; The above will output "C++ r00l3z!" because cxx_comm and MPI::COMM_WORLD are handles referring to the same underlying communicator. Hence, the only state that the handles have is whatever refers to their back-end MPI object. Having Set_name() be const keeps the *handle* const, not the underlying MPI object. Tying this all together: 1. cxx_comm.Set_name() *cannot* change state on the cxx_comm handle because cxx_comm.Get_name() and MPI::COMM_WORLD.Get_name() must return the same results (the same is true for error handlers). Hence, regardless of the implementation of the C++ bindings, the handle value cannot change. Therefore, this method (and all the others like it) should be const. 2. As a related issue, if no one can remember why the "special case" exists for OUT, then I think we should remove this text and then change all those INOUT parameters for the functions I cited in my earlier proposal to IN. This would make the C++ bindings consistent with the IN/OUT/INOUT specifications of the language-neutral bindings. 3. All the MPI C++ predefined handles should be const for many of the same reasons. Regardless of what happens to the underlying MPI object, the value of the handle cannot ever change. This is guaranteed by MPI-2:2.5.4 pages 10 lines 38-41: "All named constants, with the exceptions noted below for Fortran, can be used in initialization expressions or assignments. These constants do not change values during execution. Opaque objects accessed by constant handles are defined and do not change value between MPI initialization MPI_INIT and MPI completion MPI_FINALIZE." Hence, they should all be "const". ----- In short: C++ gives us stronger protections to ensure that applications don't shoot themselves in the foot. If the MPI predefined handles are const, then statements like "MPI::INT = my_dtype;" will fail to compile. This is a Good Thing. The original C++ bindings tried to take advantage of const, but missed a few points. Ballot two and one of the items in ballot 3 incorrectly tried to fix these points by removing const in several places. That "fixes" the problem, but removes many of the good qualities that we can get in C++ with "const". So let's fix the real problem and leave "const" in the C++ bindings. Are you confused yet? :-) -- Jeff Squyres Cisco Systems

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 22 Jan '08

22 Jan '08

An alternative-proposal would be to add a clarifying sentence in Terms and Conventions, MPI-2.0 Sect. 2.5.1, page 9, line 7: Handle arguments can be marked at INOUT to indicate that the handle itself may be changed by the routine (e.g., in MPI_TYPE_COMMIT), or to indicate that the object referenced by the handle may be changed but the handle itself is kept unchanged (e.g., MPI_TYPE_SET_NAME). Rolf Rabenseifner On Mon, 21 Jan 2008 09:42:02 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >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 > 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: 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 11:48 AM, Rolf Rabenseifner wrote: > As far as I know, this propsal is technical wrong: > MPI-2, Sect.2.5.4, page 10, lines 40-41 clearly allows the changing of > the value of MPI::COMM_WORLD and MPI::COMM_SELF in MPI_Init and > MPI_Finalize. > Therefore, I do not expect, that const is correct. Hmm. If you include the previous two lines (38-41), I read the overall interpretation as the opposite of what you are saying: "All named constants, with the exceptions noted below for Fortran, can be used in initialization expressions or assignments. These constants do not change values during execution. Opaque objects accessed by constant handles are defined and do not change value between MPI initialization MPI_INIT and MPI completion MPI_FINALIZE. To me, that says that the *MPI objects* ("object" in the MPI sense, not the C++ sense) do not change value between INIT and FINALIZE, but the *handles* must be valid for initialization before INIT. I think that the overloading of the word "object" is what is confusing here. Yes, the predefined MPI C++ handles such as MPI::COMM_WORLD are C++ objects (in the C++ sense of the word "object"). But in the MPI sense, MPI::COMM_WORLD and friends are *handles*, representing back- end MPI objets (in the MPI sense of the word "object"). It is critical to keep the difference between the two in mind. The "opaque objects" referred to in MPI-2:2.5.4 are *MPI* objects, not C++ objects. The C++ MPI named constants are just like the C MPI named constants: they must be suitable for initialization [before MPI_INIT] and cannot change value during execution. For example, this code is valid: int main(int argc, char* argv[]) { MPI::Intracomm cxx_comm = MPI::COMM_WORLD; MPI_Comm c_comm = MPI_COMM_WORLD; MPI_Init(NULL, NULL); if (SENDER == MPI::COMM_WORLD.Get_rank()) { // The cxx_comm and c_comm handles are valid even though they were // assigned before MPI_INIT cxx_comm.Send(...); MPI_Send(..., c_comm); else if (RECEIVER == MPI::COMM_WORLD.Get_rank()) { // receive stuff } MPI_Finalize(); return 0; } > Remember that in Ballot 1&2, the MPI Forum already decided > MPI-2 Page 343, line 44 > Remove the const from const MPI::Datatype. > Page 344, lines 13, 23, 32, 38, and 47 > Remove the const from const MPI::Datatype. > Page 345, lines 5 and 11 > Remove the const from const MPI::Datatype. > See http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/errata… Correct. But see my other proposal about restoring those const's (subject: "const" predefined MPI C++ handles"). > And on Jan. 2008 meeting, positve straw vtes wer given for > (in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ballot… > ) > 6. MPI-2, page 345, line 37: Remove the const from const MPI::Op. > MPI-2, page 346, line 20: Remove the const from const MPI::Group. > MPI-2, page 346, add after line 34: > Advice to implementors. If an implementation does not change > the value of > predefined handles while execution of MPI Init, the > implementation is free to > define the predefined operation handles as const MPI::Op and > the predefined > group handle MPI::GROUP EMPTY as const MPI::Group. Other > predefined > handles must not be const because they are allowed as INOUT > argument in > the MPI COMM SET NAME/ATTR and MPI TYPE SET NAME/ATTR routines. Note that this exact item did *not* come up in Bill's slides in the Chicago Jan 08 meeting. It was on the ballot, but this specific item did not get raised during the meeting (so it did not get positive straw votes). Hubert pointed out this item to me on Wednesday and I didn't remember it coming up on Monday or Tuesday. So I asked Bill about it on Wednesday after the meeting; he wasn't sure that he had remembered to put this specific item in the ballot 3 discussion during the meeting. I don't have notes about this item in the discussion, either. I may have missed it...? (but I usually tend to perk up at C++ items) > I'll move this item from Ballot 3 to Ballot 4 because the last > sentence > is not needed when your Proposal "Ballot 4 proposal: INOUT arguments" > will be accepted. All of these ballots are unfortunately intertwined, even though they are technically separate issues -- sorry, everyone! Note that these 3 proposals, taken together, represent a very, very complex set of issues. I have another rollup mail coming on these issues... please stand by. I am struggling to distill a short, concise, easy-to-understand explanation of the issues involved -- I spent a lot of time with Andrew Lumsdaine and Erez today discussing exactly these issues... > > Best regards > Rolf > > On Mon, 21 Jan 2008 10:40:39 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> 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 >> >> _______________________________________________ >> 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) > -- Jeff Squyres Cisco Systems

1 0