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

Mon May 19 08:21:25 CDT 2014

Bill,

your text goes beyond the errata goal.

The errata goal was:
  - adding the missing Status conversion
  - adding MPI_SIZEOF

And this works as errata.

Your goal is to allow also 
 - Fortran non-interceptable for these routines.

Your additional Change is to allow other methods 
than C macros for C.
This would prevent "#ifdef MPI_Wtime".

All this would be MPI-4.0 and not MPI-3.0 errata.

Rolf

----- Original Message -----
> From: "Bill Long" <longb at cray.com>
> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> Sent: Monday, May 19, 2014 2:57:41 PM
> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
> 
> 
> On May 19, 2014, at 5:27 AM, Rolf Rabenseifner <rabenseifner at hlrs.de>
> wrote:
> 
> > About https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428
> > 
> >> It is far better to say what you mean, that say something which
> >> most
> >> people believe is equivalent, because it won't be for all
> >> compilers
> >> or necessarily so in the future.
> > 
> > Yes, therefore I would like to see a wording like
> > 
> >  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 Sections 17.2.4 and 17.2.5, and no others, as macros in C.
> >  ***MPI_SIZEOF and PMPI_SIZEOF may also be implemented
> >  such that they may not be interceptable.***
> > 
> >  Advice to implementors. Implementors should document
> >  which routines are implemented as macros ***or otherwise
> >  non-interceptable***. (End of advice to implementors.)
> > 
> >  Advice to users. If these routines are implemented
> >  as macros ***or otherwise non-interceptable***, they will not
> >  work with the MPI profiling interface. (End of advice to users.)
> > 
> > 
> > But for an Erratum, it should be a minimal change.
> > Currently, C applications can test wether a MPI_Wtime macro is
> > defined.
> > There is no need to change this.
> > 
> > For Fortran, I learnt from these mails, that we Need to scpecify
> > the
> > outcome: non-intereptable.
> 
> 
> I’m still concerned about making a distinction between Fortran and C
> that is entirely artificial.  If a Fortran program wants to avoid
> interception of MPI_WTICK, for example, it is trivial to write a
> wrapper C function my_wtick_ that contains the macro for MPI_Wtick.
>  Macros in C are just another form of inlining. I think it would be
> better to merge together text from Martin and Rolf to end up with
> something simpler and clearer:
> 
> 
>  An implementation is allowed to implement MPI_WTIME,
>  MPI_WTICK, PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the
>  handle-
>  and status-conversion functions (MPI_Group_f2c, etc.)
>  in Sections 17.2.4 and 17.2.5, and no others, such that they are not
>  interceptable.
> 
>  Advice to implementors. Implementors should document
>  which routines are implemented such that they are not interceptable.
>  (End of advice to implementors.)
> 
>  Advice to users. If these routines are implemented
>  as not interceptable, they will not
>  work with the MPI profiling interface. (End of advice to users.)
> 
> 
> 
> 
> 
> > 
> > Best regards
> > Rolf
> > 
> > ----- Original Message -----
> >> From: "N.M. Maclaren" <nmm1 at cam.ac.uk>
> >> To: "MPI-WG Fortran working group"
> >> <mpiwg-fortran at lists.mpi-forum.org>
> >> Cc: mpiwg-tools at lists.mpi-forum.org
> >> Sent: Sunday, May 18, 2014 12:02:32 PM
> >> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF
> >> not profiled
> >> 
> >> On May 18 2014, Martin Schulz wrote:
> >>> 
> >>> I agree with what you are planning to propose, I am not sure,
> >>> though, the
> >>> wording is quite right, and with this I mean more the wording in
> >>> the
> >>> existing standard: this sound like as if all these functions are
> >>> still
> >>> interceptable in Fortran.
> >>> 
> >>> What if we say:
> >>> 
> >>> An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
> >>> PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the
> >>> handle-conversion
> >>> functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others,
> >>> as
> >>> macros in C or allow them to be inlined.
> >>> 
> >>> Advice to implementors. Implementors should document which
> >>> routines
> >>> are
> >>> implemented as macros or are implemented so that they can be
> >>> inlined. (End
> >>> of advice to implementors.)
> >>> 
> >>> Advice to users. If these routines are implemented as macros or
> >>> are
> >>> inlined, they will not work with the MPI profiling interface.
> >>> (End
> >>> of
> >>> advice to users.)
> >> 
> >> Basically, what you are doing is spelling out what the term
> >> 'inline'
> >> means in MPI, but it is STILL technically wrong and remains
> >> confusing.
> >> Lots of compilers generate multiple calling sequences with
> >> different
> >> properties - that is near-universal for library calls, but isn't
> >> rare
> >> for highly optimised user ones.  Well, those are not inlined, and
> >> not
> >> interceptable.
> >> 
> >> That is also true in C and C++, incidentally, where the word
> >> 'inline'
> >> means two subtly different things, neither of which is
> >> particularly
> >> close to the concept on 'inlining' being debated in this thread.
> >>  But
> >> that mess originated in C99, where 'inline' had a LOT of
> >> opposition
> >> on
> >> precisely these grounds.
> >> 
> >> It is far better to say what you mean, that say something which
> >> most
> >> people believe is equivalent, because it won't be for all
> >> compilers
> >> or
> >> necessarily so in the future.
> >> 
> >> 
> >> Regards,
> >> Nick Maclaren.
> >> 
> >> 
> >> _______________________________________________
> >> 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
> 
> 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
> 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)