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

Ballot 4 - Re: MPI Process Topologies - discussion?
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: 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… Based on the questions for clarification, I propose: Proposal for MPI 2.1, Ballot 4: ------------------------------- MPI-1.1, Sect. 6.5.3, page 181, line 1-3 read: If the size, nnodes, of the graph is smaller than the size of the group of comm, then some processes are returned MPI_COMM_NULL, in analogy to MPI_CART_CREATE and MPI_COMM_SPLIT. but should read If the size, nnodes, of the graph is smaller than the size of the group of comm, then some processes are returned MPI_COMM_NULL, in analogy to MPI_CART_CREATE and MPI_COMM_SPLIT. If the graph is empty, i.e., nnodes == 0, then MPI_COMM_NULL is returned in all processes. ------ Rationale for this clarification: As in MPI_COMM_CREATE, empty groups are allowed, but empty groups are described here in a different way, and should be mentioned explicitly therefore. ------------------------------- After MPI-1.1, Sect. 6.5.3, page 181, line 35, the following paragraph should be added: It is allowed that at a process, a neighbor process is defined multiple in the list of neighbors (i.e., multiple edges). It is also allowed that a process is neighbor to itself (i.e., a self loop in the graph). It is allowed, that the adjacency matrix is not symmetric. Advice to users. Whether using of multiple edges or a non-symmetric adjacency matrix may have possible performance implications is not defined by this standard. The definition of a node-neighbor edge does not imply a direction of the communication. (End of advice to users.) ------ Rationale for this clarification: The Example 6.3, MPI-1.1, page 15, line 29 - page 186, line 13, clearly shows multiple edges between nodes and self loops: the two (multiple) self-loops of node 0 and of node 7. It is nowhere forbidden, that the graph has edges only in one direction. ------------------------------- After MPI-1.1, Sect. 6.4, page 178, end of the sentence on lines 6-7, the following sentence should be added: All input arguments must have identical values on all processes of the group of comm_old. ------ Rationale for this clarification: This statement is missing. ------------------------------- I have split this discussion track into this track on graph topologies and an additional track (will come) on 0-dim MPI_CART_CREATE and MPI_CART_SUB. 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

Ballot 4 - Re: MPI-2 thread safety and collectives
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: Thread safety and collective communication 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… After checking the e-mails and looking at - MPI-2 8.7.2 page 195 lines 6-9 Collective calls Matching of collective calls on a communicator, window, or file handle is done according to the order in which the calls are issued at each process. If concurrent threads issue such calls on the same communicator, window or file handle, it is up to the user to make sure the calls are correctly ordered, using interthread synchronization. - MPI-2 6.2.1 Window Creation, page 110, lines 10-12: The call returns an opaque object that represents the group of processes that own and access the set of windows, and the attributes of each window, as specified by the initialization call. - MPI-2 9.2. Opening a File, page 211, line 46 - page 212, line 2: Note that the communicator comm is unaffected by MPI FILE OPEN and continues to be usable in all MPI routines (e.g., MPI SEND). Furthermore, the use of comm will not interfere with I/O behavior. it seems that the standard should be clarified. Proposal for MPI 2.1, Ballot 4: ------------------------------- Add new paragraphs after MPI-2, 8.7.2 page 195 line 9 (the end of the clarification on "Collective calls"): Advice to users. With three concurrent threads in each MPI process of a communicator comm, it is allowed that thread A in each MPI process calls a collective operation on comm, thread B calls a file operation on an existing filehandle that was formerly opened on comm, and thread C invokes one-sided operations on an existing window handle that was also formerly created on comm. (End of advice to users.) Rationale. As already specified in MP_FILE_OPEN and MI_WIN_CREATE, a file handle and a window handle inherit only the group of processes of the underlying communicator, but not the communicator itself. Accesses to communicators, window handles and file handles cannot affect one another. (End of rationale.) Advice to implementors. If the implementation of file or window operations wants to internally use MPI communication then a duplicated communicator handle may be cached on the file or window handle. (End of advice to implementors.) ------------------------------- Reason: The emails have shown, that the current MPI-2 text can be well misunderstood. ------------------------------- 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] Ballot 4 proposal: MPI::COMM_WORLD and MPI::COMM_SELF should be const
by unknown＠example.com 21 Jan '08

21 Jan '08

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. 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… 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. 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. 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)

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 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