On May 19, 2014, at 5:27 AM, Rolf Rabenseifner <[email protected]> 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" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long [email protected] 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