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

Re: [mpi-21] Inconsistent error behavior of multiple completion routines
by unknown＠example.com 29 Jan '08

29 Jan '08

Rolf, Answers inline below. Bill On Jan 28, 2008, at 11:33 AM, Rolf Rabenseifner wrote: > Bill, > > please, can you specify more precisely: > > - Is your proposal necessary for MPI_Wait/Test_some/all > (but not for MPI_Wait/Test or MPI_Wait/Test_any) That is correct. It applies only if MPI_ERR_IN_STATUS may be returned by the routine; that is for MPI_{Wait,Test}_{some,all} . > - Should it be inserted 4 times at the 4 routines, or can it be > done once > somewhere at errorhandling? It is probably better to insert it once but have each affected routine clearly point at the one discussion. > - should you substitute "valid communicators (including File > operations)" > by "valid communicators and file handles"? Probably. > - error handler on MPI_COMM_WORLD --> how is it for file handles? This is tricky. The idea is to use the error handler that is used when there is no other obvious error handler, and in the rest of MPI, that is MPI_COMM_WORLD. If it is clear that the request is an MPI I/ O request, then the error handler on MPI_FILE_NULL should be invoked, to be consistent with the operations on files. > - default for file handles is _MPI_ERRORS_RETURN! Yes, but this should be ok. For uses of these routines where all of the requests are MPI I/O requests, the error handler on the file object will be used. If the parameters to the routine are bad (e.g., a negative count), then the error handler on MPI_COMM_WORLD will be invoked. That seems fine. > and reply this on the mpi-21_at_[hidden] as a Ballot 4 issue (if > you want) > > I expect, it is the best to give this still valid topic from 2001 > back to the author of the topic :-) > > Thanks and best regards > Rolf > ___________________________________ > This is a inquity for detailed specification for MPI 2.1, Ballot 4. > > This is a follow up to: > Error handler for multiple completions > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/waitallerr/ > ___________________________________ > > 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) > William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [mpi-21] MPI_FINALIZE
by unknown＠example.com 29 Jan '08

29 Jan '08

I think that we're fine as is, and can move this to the discussed but require no change page. Bill On Jan 28, 2008, at 11:52 AM, Rolf Rabenseifner wrote: > Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, > Nicholas Nevin, > Bill Gropp, Dick Treumann > > This is a follow up to: > MPI_FINALIZE in MPI-2 (with spawn) > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/finalize/ > _________________________________________ > > When I understand correctly, then a clarification is not needed > because the MPI standard expresses all, i.e. > - MPI_Finalize need not to behave like a barrier > - but is allowed to have a barrier inside. > - If the user wants to exit one spawned process while > the others still continue to work, he/she must > disconnect this process before calling MPI_Finalize on it. > > If somebody wants a clarification to be included into the standard > and therefore in Ballot 4, please send me your wording > with the page and line references included. > > If all agree, that no clarification is needed, then I would finish > this track. > > 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 > William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [mpi-21] IEEE Floating point
by unknown＠example.com 29 Jan '08

29 Jan '08

Mainly to Marc Snir and Jim Cownie, who have contributed to this mail-discussion thread. This is a follow up to: IEEE Floating Point Behavior 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… _________________________________________ If you want a clarification to be included into the standard and therefore, e.g., in MPI 2.1 Ballot 4, please send me your wording with the page and line references to MPI 1.1 or/and MPI 2.0 included. If all agree, that no clarification is needed, then I would finish this track. 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] Two MPI I/O questions
by unknown＠example.com 29 Jan '08

29 Jan '08

Mainly to Leonard Wisniewski and Rajeev Thakur who have contributed to this mail-discussion thread. This is a follow up to: Shared File Pointers 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… and here only to the second topic in the mails. (The first topic is handled in the thread "MPI C++ Constants conflict with stdio") _________________________________________ When I understand correctly, then a clarification is not needed in the MPI standard. If somebody wants a clarification to be included into the standard and therefore in Ballot 4, please send me your wording with the page and line references included. If all agree, that no clarification is needed, then I would finish this discussion-thread. 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: clarification text for MPI_Reduce_scatter
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a follow-up for MPI 2.1, Ballot 4. I'm asking especially Rajeev Thakur, the participant of the email-discussion in 2002, to review this proposal. I would finish the following track without any proposed clarification, because the text is already clear when the MPI-1.1 part of MPI_Reduce_scatter is put in front of the MPI-2.0 part, i.e., in the upcoming combined document MPI-2.1. This is a follow up to: MPI_IN_PLACE for MPI_Reduce_scatter 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… ___________________________________ The currently text in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… should not be accepted, because it is a significant modification of the MPI-2.0 standard and would break user code: Proposed text to replace lines 16-20, pg 163 The "in place" option for intracommunicators is specified by passing MPI_IN_PLACE in the sendbuf argument. In this case, on each process, the input data is taken from recvbuf. Process i gets the ith segment of the result, and it is stored at the location corresponding to segment i in recvbuf. ___________________________________ 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 - Re: MPI-2 standard issues -MPI_Type_create_f90_...
by unknown＠example.com 29 Jan '08

29 Jan '08

Trivial wording change in the proposal... To prevent the creation of a potentially huge amount of handles, should be To prevent the creation of a potentially huge number of handles, -- Jim James Cownie <james.h.cownie_at_[hidden]> SSG/DPD/PAT Tel: +44 117 9071438 > -----Original Message----- > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > Behalf Of Rolf Rabenseifner > Sent: 29 January 2008 10:29 > To: mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 - Re: MPI-2 standard issues - > MPI_Type_create_f90_... > > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially > Nicholas Nevin, Bill Gropp, the participants of the email-discussion in > 2001, > and all implementors of MPI libraries > to review this proposal carefully. > > This is a follow up to: > MPI_Type_create_f90_real etc. > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/typef90real/ > > Problem: An application may repeatedly call (probably with same (p,r) > combination) the MPI_TYPE_CREATE_F90_xxxx routines. > ___________________________________ > > Proposal: > Add after MPI-2.0 Sect. 10.2.5, MPI_TYPE_CREATE_F90_xxxx, page 295, line > 47 > (End of advice to users.): > > Advice to implementors. > An application may often repeat a call to MPI_TYPE_CREATE_F90_xxxx > with same combination of (xxxx, p, r). > The application is not allowed to free the returned predefined, unnamed > datatype handles. > To prevent the creation of a potentially huge amount of handles, > the MPI implementation should always return the same datatype handle > for the same (REAL/COMPLEX/INTEGER, p, r) combination. > Checking for the combination (p,r) in the preceding call to > MPI_TYPE_CREATE_F90_xxxx and using a hash-table to find formerly > generated handles should limit the overhead of finding a previously > generated with same combination of (type,p,r). > (End of advice to implementors.) > ___________________________________ > Rationale for this clarification: > Currently most MPI implementations are handling the > MPI_TYPE_CREATE_F90_xxxx functions wrong or not with the requested > quality: > Current implementatios do: > > - Return of a predefined named handle based on the mapping specified > in MPI-2.0 page 296, e.g., returning MPI_REAL4, MPI_REAL8, or > MPI_REAL16: > --> wrong return from MPI_TYPE_GET_ENVELOPE > --> no problem, if the application calls MPI_TYPE_CREATE_F90_xxxx > in a loop with millions of iterations. > --> A good work around as long as MPI_TYPE_GET_ENVELOPE is not > used directly by the application. > Indirect usage in MPI parallel file I/O may not be a problem, > because with datarep=external32 the same mapping is specified > by the MPI-2.0 standard, page 296) > Example: OpenMPI > > - Return of a correct predefined, unnamed datatype handle with > (type,p,r) > cached, but in each call with same input, a new datatype handle is > returned: > --> correct return from MPI_TYPE_GET_ENVELOPE > --> i.e., totally correct implementation according to MPI-2.0 > --> waste of memory space, if the application calls > MPI_TYPE_CREATE_F90_xxxx in a loop with millions of iterations. > Example: NEC MPI/EX > > I'm not aware of an implementation that is currently correct and that > handles milions of calls with same combination of (type,p,r) > without performance problems in space or time. > ___________________________________ > > Alternative proposal: > > Instead of giving the implementation hint in form of the advice to > implementors, the MPI Forum can modify the MPI standard and require > that for each call to MPI_TYPE_CREATE_F90_xxxx a new datatype handle > is generated and that this may be freed if no longer in use (if the > user may not waste space). > > Because this alternative proposal may break existing application code, > it would be an MPI 3.0 proposal. > > 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 - Re: MPI-2 standard issues - MPI_Type_create_f90_...
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Nicholas Nevin, Bill Gropp, the participants of the email-discussion in 2001, and all implementors of MPI libraries to review this proposal carefully. This is a follow up to: MPI_Type_create_f90_real etc. 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… Problem: An application may repeatedly call (probably with same (p,r) combination) the MPI_TYPE_CREATE_F90_xxxx routines. ___________________________________ Proposal: Add after MPI-2.0 Sect. 10.2.5, MPI_TYPE_CREATE_F90_xxxx, page 295, line 47 (End of advice to users.): Advice to implementors. An application may often repeat a call to MPI_TYPE_CREATE_F90_xxxx with same combination of (xxxx, p, r). The application is not allowed to free the returned predefined, unnamed datatype handles. To prevent the creation of a potentially huge amount of handles, the MPI implementation should always return the same datatype handle for the same (REAL/COMPLEX/INTEGER, p, r) combination. Checking for the combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and using a hash-table to find formerly generated handles should limit the overhead of finding a previously generated with same combination of (type,p,r). (End of advice to implementors.) ___________________________________ Rationale for this clarification: Currently most MPI implementations are handling the MPI_TYPE_CREATE_F90_xxxx functions wrong or not with the requested quality: Current implementatios do: - Return of a predefined named handle based on the mapping specified in MPI-2.0 page 296, e.g., returning MPI_REAL4, MPI_REAL8, or MPI_REAL16: --> wrong return from MPI_TYPE_GET_ENVELOPE --> no problem, if the application calls MPI_TYPE_CREATE_F90_xxxx in a loop with millions of iterations. --> A good work around as long as MPI_TYPE_GET_ENVELOPE is not used directly by the application. Indirect usage in MPI parallel file I/O may not be a problem, because with datarep=external32 the same mapping is specified by the MPI-2.0 standard, page 296) Example: OpenMPI - Return of a correct predefined, unnamed datatype handle with (type,p,r) cached, but in each call with same input, a new datatype handle is returned: --> correct return from MPI_TYPE_GET_ENVELOPE --> i.e., totally correct implementation according to MPI-2.0 --> waste of memory space, if the application calls MPI_TYPE_CREATE_F90_xxxx in a loop with millions of iterations. Example: NEC MPI/EX I'm not aware of an implementation that is currently correct and that handles milions of calls with same combination of (type,p,r) without performance problems in space or time. ___________________________________ Alternative proposal: Instead of giving the implementation hint in form of the advice to implementors, the MPI Forum can modify the MPI standard and require that for each call to MPI_TYPE_CREATE_F90_xxxx a new datatype handle is generated and that this may be freed if no longer in use (if the user may not waste space). Because this alternative proposal may break existing application code, it would be an MPI 3.0 proposal. 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_Abort nit
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Karl Feind, Bill Gropp, Andrew Lumsdaine, Dick Treumann, the participants of the email-discussion in 2001, to review this proposal. This is a follow up to: MPI_Abort 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: MPI-1.1 Sect. 7.5, MPI_Abort, page 200, lines 23-26 read: This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program or an abort(errorcode). but should read (" or an abort(errorcode)" removed): This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program. ___________________________________ Rationale for this clarification: POSIX defines void abort(void). The routine void exit(int status) may be used to implement "handle this as a return errorcode from the main program". abort(errorcode) was not substituted by exit(errorcode) because this is technically not enough, if the MPI implementation wants to return it also from mpiexec, see next proposal. ___________________________________ Proposal: Add after MPI-1.1 Sect. 7.5, MPI_Abort, page 200, line 34 (end of rationale): Advice to users. Whether the errorcode is returned from the executable or from the MPI process startup mechanism (e.g., mpiexec), is an aspect of quality of the MPI library but not mandatory. (End of advice to users.) ___________________________________ Rationale for this clarification: The intent of word "should" in "should handle this as a return errorcode from the main program" is only a quality of implementation aspect and not a must. This is not clear and can be misinterpreted. ___________________________________ 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] MPI_FINALIZE
by unknown＠example.com 28 Jan '08

28 Jan '08

Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, Nicholas Nevin, Bill Gropp, Dick Treumann This is a follow up to: MPI_FINALIZE in MPI-2 (with spawn) 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… _________________________________________ When I understand correctly, then a clarification is not needed because the MPI standard expresses all, i.e. - MPI_Finalize need not to behave like a barrier - but is allowed to have a barrier inside. - If the user wants to exit one spawned process while the others still continue to work, he/she must disconnect this process before calling MPI_Finalize on it. If somebody wants a clarification to be included into the standard and therefore in Ballot 4, please send me your wording with the page and line references included. If all agree, that no clarification is needed, then I would finish this track. 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: Re: SEND COUNT and RECEIVE COUNT
by unknown＠example.com 28 Jan '08

28 Jan '08

Bill, please can you forward this to Yukiya Aoyama <aoyama_at_...>, the originator of this track. Thanks, Rolf ___________________________________ This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Description of the send and receive count arguments to MPI_Alltoallv 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 not to include any further clarification into the standard. Reason: MPI-1, Sect. 4.8, MPI_ALLTOALLV, page 112, lines 37-40 clearly states: "The type signature associated with sendcount[j], sendtype at process i must be equal to the type signature associated with recvcount[i], recvtype at process j. This implies that the amount of data sent must be equal to the amount of data received, pairwise between every pair of processes. Distinct type maps between sender and receiver are still allowed." The same text is also used for MPI-2.0, Sect. 7.3.5 MPI_ALLTOALLW, page 165, lines 42-45. Okay? 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