[MPIWG Fortran] Profiling for MPI_SIZEOF?

[Bill Long]

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).
> 
Correct.

> 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
interface MPI_Sizeof                                                                               
   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.

Cheers,
Bill

> 
> Thoughts?
> 
> -- 
> 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

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