[MPIWG Fortran] Profiling for MPI_SIZEOF?
Jeff Squyres (jsquyres)
jsquyres at cisco.com
Thu May 15 15:38:09 CDT 2014
On May 15, 2014, at 4:26 PM, Bill Long <longb at cray.com> wrote:
>> 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.
I thought gfortran supported TYPE(*) DIMENSION(*), not DIMENSION(..). Is that incorrect?
My apologies about incorrectly citing the Cray compiler! :-(
> 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.
No, there's 10 * 7 versions, right? One for each type (10), and then 1 for each rank.
The language in the MPI spec explicitly allows you to pass an array as the argument of x (although it does say that it will return the size of the base element -- not the array).
>> 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.)
Oh -- good point; forgot about those...
> Actually, I’d make the same argument for the conversion routines between the various forms of MPI_Status.
The c2f/f2c functions are defined to be not profile-able, so we're ok there.
>> 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
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
More information about the mpiwg-fortran