[MPIWG Fortran] Proposal: MPI_SIZEOF not profiled

Rolf Rabenseifner rabenseifner at hlrs.de
Fri May 16 08:59:41 CDT 2014


Samll updates, see below.

I corrected the page number and I added 
 - "or inlined in Fortran", and
 - the status-conversion routines in 17.2.5
   (They were new in MPI-3.0 and we oversaw that they
    have similar quality as handle-conversion routines.
    Major difference, they have an out-argument 
    within the argument list.)

Do we also consensus in adding the status-conversions
to the macro+inline-allowence?
Or do we need to spilt these two things?

Rolf

----- Original Message -----
> From: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> To: "MPI Fortran WG" <mpiwg-fortran at lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools at lists.mpi-forum.org>
> Sent: Friday, May 16, 2014 2:44:10 PM
> Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
> 
> Fortran and Tools WGs:
> 
> (=== this is a bit urgent if we want to get this read at the Chicago
> meeting; the T-2 deadline is this upcoming Monday morning ===)
> 
> We seem to have some measure of consensus on the other thread that
> MPI_SIZEOF should not be profiled.
> 
> Note, however, that the Tools chapter currently mandates that PMPI_
> versions of all MPI routines must be available (including, for
> example, MPI_WTICK), but the MPI_ versions do not have to be
> replaceable at link time.  I propose adopting this convention for
> MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF).
> 
> Does this wording work as a proposal?
> 
  MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads:
  (Jeff, you may used a wrong pdf with ther page numbers)
> 
> -----
> An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
> PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions
> (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in
> C.
> 
> Advice to implementors. Implementors should document which routines
> are implemented as macros. (End of advice to implementors.)
> 
> Advice to users. If these routines are implemented as macros, they
> will not work with the MPI profiling interface. (End of advice to
> users.)
> -----
> 
> but should read (new text in ***):
> 
> -----
> An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
> PMPI_WTIME, PMPI_WTICK, and the handle- 
  ***and status-***
> conversion functions
> (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, 
> and no others, as macros in C
  ***or inlined in Fortran***.
> ***MPI_SIZEOF may also be inlined.***
> 
> Advice to implementors. Implementors should document which routines
> are implemented as macros ***or otherwise inlined***. (End of advice
> to implementors.)
> 
> Advice to users. If these routines are implemented as macros ***or
> otherwise inlined***, they will not work with the MPI profiling
> interface. (End of advice to users.)
> -----
> 
> p555:31-37 (first page of the Tools chapter) currently says:
> 
> -----
> 1. provide a mechanism through which all of the MPI defined
> functions, except those allowed as macros (See Section 2.6.4), may
> be accessed with a name shift.  This requires, in C and Fortran, an
> alternate entry point name, with the prefix PMPI_ for each MPI
> function in each provided language binding and language support
> method.  For routines implemented as macros, it is still required
> that the PMPI_ version be supplied and work as expected, but it is
> not possible to replace at link time the MPI_ version with a
> user-defined version.
> -----
> 
> but should say
> 
> -----
> 1. provide a mechanism through which all of the MPI defined
> functions, except those allowed as macros ***or otherwise inlined***
> (See Section 2.6.4), may be accessed with a name shift.  This
> requires, in C and Fortran, an alternate entry point name, with the
> prefix PMPI_ for each MPI function in each provided language binding
> and language support method.  For routines implemented as macros
> ***or otherwise inlined***, it is still required that the PMPI_
> version be supplied and work as expected, but it is not possible to
> replace at link time the MPI_ version with a user-defined version.
> -----
> 
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> 

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
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: Room 1.307)



More information about the mpiwg-fortran mailing list