[MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
N.M. Maclaren
nmm1 at cam.ac.uk
Sun May 18 05:02:32 CDT 2014
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.
More information about the mpiwg-fortran
mailing list