[mpi-21] Ballot 4 - Re: MPI-2 standard issues -MPI_Type_create_f90_...
Cownie, James H
james.h.cownie at [hidden]
Tue Jan 29 04:40:46 CST 2008
Trivial wording change in the proposal...
To prevent the creation of a potentially huge amount of handles,
To prevent the creation of a potentially huge number of handles,
James Cownie <james.h.cownie_at_[hidden]>
Tel: +44 117 9071438
> -----Original Message-----
> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]]
> 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 -
> This is a proposal for MPI 2.1, Ballot 4.
> I'm asking especially
> Nicholas Nevin, Bill Gropp, the participants of the email-discussion
> 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-
> with mail discussion in
> Problem: An application may repeatedly call (probably with same (p,r)
> combination) the MPI_TYPE_CREATE_F90_xxxx routines.
> Add after MPI-2.0 Sect. 10.2.5, MPI_TYPE_CREATE_F90_xxxx, page 295,
> (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,
> 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
> 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
> --> 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
> cached, but in each call with same input, a new datatype handle is
> --> 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
> Example: NEC MPI/EX
> I'm not aware of an implementation that is currently correct and
> 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
> 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
More information about the Mpi-21