[mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled

Fri May 16 10:19:37 CDT 2014

I agree with everything (good catch on the status conversion routines), but I think the "***or inlined in Fortran***" phrase is a separate/new thing.

Fortran was specifically not mentioned in the original text (w.r.t. WTICK and WTIME); if we want to change that, I think that's a separate/new thing.  It could have ABI issues, for example, and would therefore have to go to MPI-4.

I think the rest of this can go in as errata.

On May 16, 2014, at 9:59 AM, Rolf Rabenseifner <rabenseifner at hlrs.de> wrote:

> 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)
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/