From: "Cownie, James H" Date: January 29, 2008 4:40:46 AM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: MPI-2 standard issues - MPI_Type_create_f90_... Reply-To: "Mailing list for discussion of MPI 2.1" 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 SSG/DPD/PAT Tel: +44 117 9071438 > -----Original Message----- > From: mpi-21-bounces@XXXXXXXXXXX [mailto:mpi-21-bounc On > Behalf Of Rolf Rabenseifner > Sent: 29 January 2008 10:29 > To: mpi-21@XXXXXXXXXXX > 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@XXXXXXX > 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@XXXXXXXXXXX > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 _______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21