[MPI3 Fortran] MPI function symbol naming convention for tools
Rolf Rabenseifner
rabenseifner at hlrs.de
Thu Jun 30 15:48:14 CDT 2011
After my email-free vacation weeks in Rome and Rimini,
I used my travel to the Fortran standardization meeting
[they extended the ASYNCHRONOUS attribute to asynchronous
(MPI) communication] to read through the total track.
As I oversee, the answers are really non-trivial
and at the end, they are related to decisions about
the implementation of callback routines:
First a pre-comment:
The mpi module _nostatus does not exist, because
in the mpi module, the MPI_STATUS_IGNORE is used.
..._nostatus is only needed in mpi_f08.
Constraints:
C1. Do not break ABI backward compatibility.
(Hubert is asolutely right!)
C2. Do not break PMPI.
(Thanks to the tools people who pointed this out)
C3. Each interface has different linker names.
These linker names are well defined and must be
used if a user wants to substitute an MPI routine
by a user-written wrapper:
- MPI_Recv for the C interface
- MPI::Recv for the C++ interface
- mpi_recv_ (or whatever the Fortran compiler has chosen)
for Fortran mpif.h or mpi module
(To understand C2 or C3, one should be familiar with
MPI-2.2, Chapter 14 "Profiling Interface".)
Name explanation:
"f08" is an abbrevation for "Fortran interface that requires
at least F2008+TR29113 for its full implementation".
"f08" does not mean that it is for F2008 compilers.
Therefore, it is not planned to have some "f13" in the future.
Since MPI-1, we only added a new C++ interface.
The new f08 interfdace is an answer to all the unsolved
problems introduced in mpif.h that is originally based
on a slightly extented Fortran 77.
Implications (e.g. for MPI_Recv):
I1. The binary routine names for mpi module and mpif.h
are and will stay the name that is the linker name
that is chosen by the Fortran compiler for MPI_Recv,
e.g. mpi_recv_ or mpi_recv__
I2. This routine can be substituted by a user-written
Fortran wrapper named MPI_RECV, which is then
mapped by the same Fortran compiler to the same
name mpi_recv_ or mpi_recv__
I3. It is not allowed to make MPI_Recv a CONTAINS routine
of the mpi module because this would be mapped to another
linker name.
I4. For the new mpi_f08 module we need to define new names
for the case that the user wants to substitute such a routine
by a wrapper.
This is necessary because MPI_Recv in the mpi_f08 module
is mapped by the Fortran compiler to the same name
as MPI_Recv in mpif.h or the mpi module.
And by the same reason as in I3, this routine must not
be part of the mpi_f08 module name space.
And now, we have the freedom to choose the names for
- MPI_Recv in mpi_f08 with the status argument
- MPI_Recv in mpi_f08 without the status argument
First, we should decide about the postfixes etc.
Second, we should decide about the language namespace.
First:
- MPI_Recv_f08 and MPI_Recv_f08_nostatus
(These names should be clear in the sense of
readable for human beeings using a debugger.
Therefore, it is a bad idea to substitute the module
abbreviation by something else, e.g. "desc".)
Other name pairs are:
- ..._f08 / ..._f08_noweights
- ..._f08 / ..._f08_nosourceweights /
..._f08_nodestweights / ..._f08_noweights
- ..._f08 / ..._f08_errcodes
Second
- The user should be able to write a wrapper or to
reuse and existing wrapper for the mpi module.
Implications: The wrapper should be writable in Fortran.
There are two alternatives:
A1. mpi_f08 is defined as bind-Fortran routines.
An existing application that has an MPI_Recv wrapper
which internally calls PMPI_Recv in the mpi module
can be substituted by the following changes:
- Application routines that call MPI_Recv are
modifired to use mpi_f08
- The wrapper routine is duplicated into two new
named routines
-- MPI_Recv_f08 with status argument
and "same" content as existing wrapper
(except of the use of handles and ierror),
-- MPI_Recv_f08_nostatus without a status argument.
A2. mpi_f08 is defined with BIND(C) routines and explicit names:
INTERFACE MPI_Recv(...)
SUBROUTINE MPI_Recv_f08(..., status, ...) BIND(C)
END
SUBROUTINE MPI_Recv_f08_nostatus(..., ...) BIND(C)
END
END
Therefore, the user has also to implement his/her wrappers
with
SUBROUTINE MPI_Recv_f08(..., status, ...) BIND(C)
END
SUBROUTINE MPI_Recv_f08_nostatus(..., ...) BIND(C)
END
or with C routines
void MPI_Recv_f08(...., MPI_F_status *status, ....)
{ .... }
void MPI_Recv_f08_nostatus(...., ....)
{ .... }
A3. Same as A2, but the MPI standard defines the C-routine names
with other lower/upper-case rules, e.g.:
- mpi_recv_f08 and mpi_recv_f08_nostatus
to signal to the user of a debugger that this is
not a C interface routine (they all use mixed MPI_Xxxx names).
- Whether we must use A1 or whether we can freely choose
between A1, A2 and A3, depends on whether all routines can
be implemented with BIND(C).
For this we have to check whether MPI_Op_create can be implemented
with BIND(C), which depends on whether the callback routines
are also defined with BIND(C) in mpi_f08.
For the tools group, it is not a big issue:
- With A1, the naming rules are the same for mpif.h & mpi module
and for the mpi_f08 module, i.e., according to the
Fortran compiler's rule.
- With A2 and A3, the naming for mpif.h & mpi module is according
to the Fortran compiler's rule and the naming for mpi_f08
with fixed "C-names"
(A2: MPI_Recv_f08 / MPI_Recv_f08_nostatus,
A3: mpi_recv_f08 / mpi_recv_f08_nostatus)
Implication:
- It should be mainly decided by the constraints
outside the tools world.
- But it should be a consistent decision that works for
routines with and without callback routines in the argument list.
Main decision that we must do:
- How must we define
-- MPI_Op_create (with a callback with choice buffer), and
-- MPI_Errhandler_create (without such a choice buffer callback)?
- Main question for this:
Which rules do we have for callbacks and BIND(C)?
(a full list of all callbacks are in MPI-2.2, page 617)
Best regards
Rolf
----- Original Message -----
> From: "Martin Schulz" <schulzm at llnl.gov>
> To: "Craig Rasmussen" <crasmussen at newmexicoconsortium.org>
> Cc: "MPI3 Tools" <mpi3-tools at lists.mpi-forum.org>, "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>
> Sent: Monday, June 27, 2011 4:24:26 PM
> Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools
> Hi all,
>
> I agree with Jeff and Craig - having a TelCon next week
> would be helpful. What about Wednesday 7/6 at 8am PDT,
> 11am EDT, 5pm MSZ, since this would also give people
> from Europe a chance to dial-in. Would this work for
> everyone/most of you? Once we have a time, I'll also
> send this to the group of tools people we had on the
> other email, in case someone wanted to join us.
>
> Martin
>
>
> On Jun 27, 2011, at 6:42 AM, Rasmussen, Craig wrote:
>
> > I finally have had a chance to read through all of the responses.
> > Hopefully I can clarify a few things without muddying the waters
> > further.
> >
> > If Martin is correct and no tools support the "use mpi" option, then
> > things are pretty simple.
> >
> > 1. mpih.f option: For the immediate future this works as it always
> > has. I was only suggesting to deprecate it. But on reconsideration,
> > I think this is the wrong thing to do. We are trying to deprecate
> > mpih.f itself so the tools using mpih.f can continue using the
> > current
> > naming convention as long as mpih.f stays around. Fortran users
> > could
> > write an MPI_Send routine and it would work with the PMPI interface
> > as
> > before (at least as I understand how this works).
> >
> > 2. use mpi or use mpi_f08 option: We would mandate that these
> > interfaces supply the names mpi_send_f, mpi_send_f_nostatus,
> > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a
> > Fortran user want to use the PMPI interface. I need to understand
> > this more and write some tests and examples we can all look at.
> >
> > So I suggest we schedule a conference call sometime next week (after
> > July 5).
> >
> > -craig
> >
> >
> > On Mon, Jun 27, 2011 at 6:38 AM, Hubert Ritzdorf
> > <Hubert.Ritzdorf at emea.nec.com> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: mpi3-fortran-bounces at lists.mpi-forum.org
> >>> [mailto:mpi3-fortran-
> >>> bounces at lists.mpi-forum.org] On Behalf Of Bill Long
> >>> Sent: Saturday, June 25, 2011 11:33 AM
> >>> To: Martin Schulz
> >>> Cc: MPI3 Tools; MPI-3 Fortran working group
> >>> Subject: Re: [MPI3 Fortran] MPI function symbol naming convention
> >>> for tools
> >>>
> >>>
> >>>
> >>> On 6/24/11 11:54 AM, Martin Schulz wrote:
> >>>
> >>>>
> >>>> This is probably my lack of knowledge in Fortran compilers, but
> >>>> is this all even possible with regular compilers: I would assume
> >>>> that you can use an MPI 3.0 implementation with Craig's proposal
> >>>> (case A) with an older F77 or F90 compiler, right? If so, one
> >>>> would
> >>>> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name
> >>>> mapping from mpi_send to mpi_send_f - I thought this was a new
> >>>> feature from F08?
> >>>>
> >>>
> >>> If you still have an old f77 compiler on you system (from decades
> >>> ago),
> >>> it will not be adequate. If you have a current version of a
> >>> Fortran
> >>> compiler available, you are in much better shape. The meaning of
> >>> "Fortran" changes over time, and the compilers progress
> >>> accordingly,
> >>> with some time delay.
> >>>
> >>> The name mapping of a call to MPI_send into a call to mpi_send_f
> >>> is
> >>> accomplished with generic interfaces. These were part of Fortran
> >>> 90 (20
> >>> year old technology now) - F08 is not required for this. Other
> >>> details
> >>> of the interfaces do require more recent standards, however.
> >>>
> >>>
> >>
> >> Craig's proposal would require at least Fortran 2003. Otherwise,
> >> the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_
> >> or
> >> mpi_send_f__.
> >>
> >> Hubert
> >>
> >> _______________________________________________
> >> mpi3-fortran mailing list
> >> mpi3-fortran at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> >>
>
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: Allmandring 30)
More information about the mpiwg-fortran
mailing list