[MPIWG Fortran] Profiling for MPI_SIZEOF?
longb at cray.com
Thu May 15 15:26:01 CDT 2014
On May 15, 2014, at 1:42 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> Question for the Fortran and Tools WGs: How does a tool intercept calls to the Fortran-only MPI_SIZEOF function? (MPI-3.0 p621)
No intercept seems right. What is the point? The generated code by the compiler is likely a single constant loaded to a register - one machine instruction. Trying to profile that seems well short of useful.
> I ask for the following reasons:
> 1. Unlike all other MPI functions, this function is keyed off the *type* of the 1st argument (not the *value* of the first argument).
> 2. Without support for TYPE(*), DIMENSION(..) (which no compiler supports yet), an MPI implementation has to provide N overloaded versions of MPI_SIZEOF to be able to determine the type of the first argument.
“no compilers” is a bit strong. Cray and gfortran both support this. However, “only a minority of compilers” is certainly true.
That said, the optimal implementation would be to write all of the specific versions (I’m seeing 10) for a generic named MPI_SIZEOF. For each specific version, the executed code reduces to
size = storage_size(x)/8
which the compiler will evaluate at compile time based on the type of x.
> 3. However, unlike how we specified the Fortran routine names in the MPI-3.0 errata so that they could be intercepted by PMPI, there are no specified specific subroutine names for the overloaded MPI_SIZEOF routines.
Right. Those got made up internally.
% grep -i sizeof mpi_f08_types.f90
! MPI_Sizeof in 17.1.9
module procedure MPI_Sizeof_xint8
module procedure MPI_Sizeof_xint16
module procedure MPI_Sizeof_xint32
module procedure MPI_Sizeof_xint64
module procedure MPI_Sizeof_xreal32
module procedure MPI_Sizeof_xreal64
module procedure MPI_Sizeof_xreal128
module procedure MPI_Sizeof_xcomplex32
module procedure MPI_Sizeof_xcomplex64
module procedure MPI_Sizeof_xcomplex128
private :: MPI_Sizeof_xint8
private :: MPI_Sizeof_xint16
private :: MPI_Sizeof_xint32
private :: MPI_Sizeof_xint64
private :: MPI_Sizeof_xreal32
private :: MPI_Sizeof_xreal64
private :: MPI_Sizeof_xreal128
private :: MPI_Sizeof_xcomplex32
private :: MPI_Sizeof_xcomplex64
private :: MPI_Sizeof_xcomplex128
> In reality, I'm assuming no tool will ever care about intercepting MPI_SIZEOF (at least, they haven't complained in the several years that Open MPI/MPICH have provided it). But it's an inconsistency in the standard.
We also don’t intercept the comparison routines that implement the == and /= operators for the new and old handles. (Again a case of trivial code where all the timing would be in the interceptor overhead.)
Actually, I’d make the same argument for the conversion routines between the various forms of MPI_Status.
> I see two obvious solutions -- perhaps there are more:
> 1. Define that MPI_SIZEOF is not able to be profiled.
> 2. For compilers that do not support TYPE(*), DIMENSION(..), define some kind of pattern of specific procedure names for the overloaded instances of MPI_SIZEOF.
> I'm in favor of #1.
Definitely like #1.
> 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
Bill Long longb at cray.com
Fortran Technical Suport & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the mpiwg-fortran