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

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

29 Jan '08

Proposal: The current text in MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read: There is one special case  if an argument is a handle to an opaque object (these terms are defined in Section 2.5.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. Thus, in C++, IN arguments are either references or pointers to const objects. but should read: There is one special case  if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call but the handle itself is not modified , then the argument is marked IN/INOUT. We use the first part (IN) to specify the use of the handle and the second part (INOUT) to specify the use of the opaque object. Thus, in C++, IN arguments are either references or pointers to const objects, IN/INOUT arguments are references to const handles to non-const objects. In all reoutines mentioned in the clarification below, the INOUT handle declaration (in MPI-2.0) and the IN handle declaration (in MPI-1.1) ist modified into a IN/INOUT handle declaaration. ____________________________ Rationale for this proposal: I have checked the total MPI 1.1 and 2.0 standard to find all routines with an argument specification according to the following declaration pattern: Language independent interface: INOUT handle C interface MPI_handletype handle We can find this pattern only in MPI-2.0 at following routines: MPI_INFO_SET / _DELETE MPI_xxxx_SET_ERRHANDLER with xxxx=COMM / TYPE / WIN MPI_GREQUEST_COMPLETE MPI_xxxx_SET_NAME with xxxx=COMM / TYPE / WIN MPI_xxxx_SET_ATTR with xxxx=COMM / TYPE / WIN MPI_xxxx_DELETE_ATTR with xxxx=COMM / TYPE / WIN MPI_FILE_SET_SIZE / _PREALLOCATE / _SET_INFO / _SET_VIEW MPI_FILE_WRITE_AT / _WRITE_AT_ALL / _IWRITE_AT MPI_FILE_READ / _READ_ALL / _WRITE / _WRITE_ALL MPI_FILE_IREAD / _IWRITE MPI_FILE_SEEK MPI_FILE_READ_SHARED / _WRITE_SHARED MPI_FILE_IREAD_SHARED / _IWRITE_SHARED MPI_FILE_READ_ORDERED / _WRITE_ORDERED MPI_FILE_SEEK_SHARED MPI_FILE_WRITE_AT_ALL_BEGIN / MPI_FILE_WRITE_AT_ALL_END MPI_FILE_READ_ALL_BEGIN / MPI_FILE_READ_ALL_END MPI_FILE_WRITE_ALL_BEGIN / MPI_FILE_WRITE_ALL_END MPI_FILE_READ_ORDERED_BEGIN / MPI_FILE_READ_ORDERED_END MPI_FILE_WRITE_ORDERED_BEGIN / MPI_FILE_WRITE_ORDERED_END MPI_FILE_SET_ATOMICITY / _SYNC All these routines keep the handle itself unchanged, but the opaque object is modified in a way, that with oother MPI routines this change can be detected. For example, an attribute is cached or changed, a file pointer is moved, the content of a file was modified. The current text in MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read: There is one special case  if an argument is a handle to an opaque object (these terms are defined in Section 2.5.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. Thus, in C++, IN arguments are either references or pointers to const objects. With this definition (that I want to change later on) the use of INOUT is correct. In MPI-1.1 we have several of such routines, but in all cases, the handle is declared only as IN. I hope, I could find all of them: MPI_ATTR_PUT / _ DELETE MPI_ERRHANDLER_SET (these routines are now deprecated, but compare with use of INOUT in MPI_COMM_SET_ATTR and MPI_COMM_DELETE_ATTR in MPI-2.0) The following proposal should remove this inconsistency and should be a basis for correct definition of const. ____________________________ I hope, with this proposal, the INOUT handle problem can be really solved. 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 29 Jan '08

29 Jan '08

From: Richard Treumann <treumann_at_[hidden]> Date: January 29, 2008 10:38:02 AM CST To: "Mailing list for discussion of MPI 2.1" <mpi-21_at_[hidden]> Subject: Re: [mpi-21] MPI_FINALIZE I do not see a need for clarification. As long as somewhere in the standard the following points are clear: 1) Only MPI_BARRIER promises barrier behavior 2) Any collective may be implemented with barrier behavior as a side effect (performance issues make some collectives (eg. MPI_Bcast) unlikely to be like a barrier like but the standard does not rule it out) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 > 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 *

1 0

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

29 Jan '08

I do not see a need for clarification. As long as somewhere in the standard the following points are clear: 1) Only MPI_BARRIER promises barrier behavior 2) Any collective may be implemented with barrier behavior as a side effect (performance issues make some collectives (eg. MPI_Bcast) unlikely to be like a barrier like but the standard does not rule it out) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/28/2008 12:52:54 PM: > 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 *

1 0

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