From: "Rolf Rabenseifner" <rabenseifner@XXXXXXX>
Date: January 29, 2008 4:28:35 AM CST
To: mpi-21@XXXXXXXXXXX
Subject: [mpi-21] Ballot 4 - Re: MPI-2 standard issues - MPI_Type_create_f90_...
Reply-To: "Mailing list for discussion of MPI 2.1" <mpi-21@XXXXXXXXXXX>

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