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

[Bill Long]

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