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