[mpi-21] Ballot 4 - Re: MPI-2 standard issues -MPI_Type_create_f90_...

[Cownie, James H]

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