[MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
Rolf Rabenseifner
rabenseifner at hlrs.de
Wed Mar 27 13:57:58 CDT 2013
After all the replies, I tried to update the list of options.
Please answer at the end the list of "straw votes",
may be also with "more clarification needed".
Option 1
- #364 as it currently is, as a minimal solution for
the LOGICAL problem.
#364 removes BIND(C) only for routines with LOGICAL arguments
and for all predefined callback routines
and on all ABSTRACT INTERFACE definitions for user written callbacks,
and all MPI routines that have such callback PROCEDURE
dummy arguments.
Tools will need to support underscore name
mangling forever (even when TS29113 is implemented by compilers) but
only on routines with LOGICAL and PROCEDURE arguments,
and for all predefined callbacks.
Pro: It is consistent between Fortran and MPI.
I.e., it is the minimal solution that we must do.
Con: It has a mix of BIND(C) and non-BIND(C) routine groups
which is ugly for the future.
Remark: non-BIND(C) will stay there because the callbacks
need non-BIND(C) in the moment and this cannot be
changed in the future by nice new concepts from
the Fortran language standardization.
Option 2a
- #364 plus changing MPI-3.0 page 605 lines 24-30 and
page 605 line 47 - page 606 line 6 by also using non-BIND(C),
but other linker names:
MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e.,
buffers are done with C-descriptors and
not with void* pointers.)
MPI_Send_fd (in the mpi module or mpif.h if
MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done
there, i.e., with the descriptors.)
The real linker name is defined through the compiler's name
mangling for these names.
This means, we remove BIND(C) from all routines.
Tools will need to support underscore name mangling
for all routines.
Pro: It is consistent between Fortran and MPI
and it is consistent within MPI, i.e., all
functionality is done with non-BIND(C) routines.
BIND(C) can be still used internally to
call MPI_Send_cdesc and MPI_Isend_cdesc.
To be fair, implementatiosn will be based mainly
on this TS 29113 feature, but only internally.
Con: No BIND(C) on the official MPI interface.
We urged Fortran to put some features into TS 29113,
but we will not use these features, because they
are not needed on this internal interface.
Option 2b
- Same as Option 2a, but allow the four options
MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)
MPI_Send_fd (mpi and mpif.h with array descriptor for buffers)
MPI_Send_f08 (mpi_f08 interface with void *, via IGNORE_TKR etc.)
MPI_Send (mpi and mpif.h with void *, via IGNORE_TKR etc.)
only for routines in the two routine groups MPI_SEND and MPI_ISEND.
For all other routine groups, we provide only the options
MPI_Send_f08 (mpi_f08 interface)
MPI_Send (mpi and mpif.h)
because there are no DIMENSION(..),TYPE(*) buffers.
Additional Pro: Reduces significantly the routine sets that
must be handled with the PMPI interface.
No additional Con.
Option 2c
- Same as 2b, but we allow that all routine groups are done with
BIND(C), except the callback routine group MPI_COMM_DUP_FN (and also
MPI_TEST (with the LOGICAL args), MPI_OP_CREATE, MPI_REGISTER_DATAREP,
and MPI_COMM_CREATE_KEYVAL as long as the required Fortran-C support
is missing).
For this, the following linker names are used, but without
name mangling:
MPI_Send_f08d (mpi_f08 interface with array descriptor for buffers)
MPI_Send_fd (mpi and mpif.h with array descriptor for buffers)
MPI_Send_f08 (mpi_f08 interface with void *, via IGNORE_TKR etc.)
MPI_Send_f (mpi and mpif.h with void *, via IGNORE_TKR etc.)
Pro: In long term, when also LOGICAL and Fortran-callback wiil
have become interoperable, an implementation can choose
to internally implement all in C based on BIND(C), except
these 9 predefined callbacks.
This is an ideal basis for option 2d.
Con: The tools people have more work.
Option 2d
- Same as 2c, but we define one additional small routine group:
Routine group MPI_STATUS_F2F08
contains MPI_STATUS_F2F08 and MPI_STATUS_F082F.
Pro: An implementor may want to choose that this routine group is
implemented in Fortran with BIND(C) and the C MPI_Status...
routines internally call these BIND(C) Fortran routines.
Con: One more routine group (a very weak argument).
Option 3:
- Option 2 plus the following rule:
- The Fortran PMPI interface can be substituted by a
wrapper based sulution that internally calls the full
MPI C interface.
- In this case, the Fortran interface should be hidden
to the tools.
- For the buffer routines with the new cdesc descriptor,
new interfaces are added for the tools people,
e.g., MPI_Send_cdesc and MPI_Isend_cdesc.
Pro:
1. The thin wrappers can be put in a module.
2. Compilers may be able to inline the wrappers for
very efficient implementations.
3. Fortran implementations are much simpler because
they won't have to directly support PMPI in Fortran.
4. Since the Fortran implementation is substantially
less complex, the costs associated with testing,
supporting, and maintaining a Fortran
implementation will also be reduced.
4. If all MPI implementations eventually choose to call
the C API, then the tools community eventually will
not have to support underscore name mangling,
thus reducing their costs as well.
Con: An additional new interface for the tools folk.
It is not backward compatible for users who really
intercept the Fortran MPI interface.
Open question: Does Option 3 require MPI-3.1 or can it
be done as an MPI-3.0 erratum.
Pro erratum: One goal of MPI-3.0 mpi_f08 was to allow
a fully standardized implementation, i.e., without
compiler dependent software (e.g., name mangling).
MPI-3.0 was supposed to do this.
The Option 3 will keep this quality.
It is a change of the PMPI Fortran interface,
but MPI-3.0 allows such changes (See removal of C++).
It is an erratum that requires at least double-vote,
if we allow this also for the mpi module and mpif.h.
Con erratum: It is a real change for the user-interface
of Fortran's PMPI.
Therefore:
- Option 3a: allowing this only for the mpi_f08 module
- Option 3b: allowing it for all three Fortran support methods.
- Option 3c: To allow this Option 3 independently for
each routine group.
Option 4:
(needed for 2c, for all others it is independent)
- Substituting in mpi_f08
all CHARACTER(LEN=xxx)
by CHARACTER(LEN=1),DIMENSION(xxx)
with xxx = a fixed constant.
As far as I understand, this cannot be done for CHARACTER(LEN=*)
because otherwise the MPI routine cannot learn about the length
of the string, see, e.g., argv array in MPI_COMM_SPAWN.
Pro: As far as I understand, this is needed for BIND(C) for the
MPI routines that have CHARACTER(LEN=xxx) dummy arguments.
Con: Non-consistent solution for a bug in TS29113 that should be
fixed in TS29113.
The mpi and the mpi_f08 moudlues will be inconsistent
to each other.
We do not want to change the old mpi module and mpif.h Fortran interface.
With current CHARACTER(LEN=xxx), the MPI routine can check at
runtime whether the provided actual argument is long enough.
With CHARACTER(LEN=1),DIMENSION(xxx), such a check is impossible.
Bill and Craig, please correct me if I'm wrong.
Is this bug fixable in TS29113, or is there a reason,
why CHARACTER(LEN=xxx) is not interoperable with C?
Open questions:
- Is anybody for Option 1?
- If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?
- For each Option 2a-d do you say
- absolute necessary
- is okay for me
- is not okay for me
- Do you want Option 3?
- If yes, do you want 3a, or 3b?
- Can we do 3a as erratum (instead of postponing to MPI-3.1)?
- Can we do 3b as erratum (instead of postponing to MPI-3.1)?
- If yes, do you additionally want 3c?
- Do you want Option 4?
-----------
My personal answers:
- Is anybody for Option 1?
** No, it is to few.
- If we are doing Option 2, which version is your favorite 2a, 2b, 2c, 2d?
** I would prefer 2d.
- For each Option 2a-d do you say
- absolute necessary
- is okay for me
- is not okay for me
** 2a: absolute necessary
** 2b: absolute necessary
** 2c: is okay
** 2d: is okay
- Do you want Option 3?
** Yes
- If yes, do you want 3a, or 3b?
** 3b
- Can we do 3a as erratum (instead of postponing to MPI-3.1)?
** Yes
- Can we do 3b as erratum (instead of postponing to MPI-3.1)?
** Yes
- If yes to 3a or b, do you additionally want 3c?
** Yes
- Do you want Option 4?
** No, should be done by the Fortran standardization
as correction to TS29113.
Best regards
Rolf
----- Original Message -----
> From: "Bill Long" <longb at cray.com>
> To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
> Cc: "Craig Rasmussen" <rasmus at cas.uoregon.edu>, "Rolf Rabenseifner" <rabenseifner at hlrs.de>, "MPI-3 Fortran working
> group" <mpi3-fortran at lists.mpi-forum.org>, "Hubert Ritzdorf" <Hubert.Ritzdorf at emea.nec.com>, "Martin Schulz"
> <schulzm at llnl.gov>, "Tobias Burnus" <burnus at net-b.de>
> Sent: Wednesday, March 27, 2013 12:03:27 AM
> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
> On 3/26/13 11:26 AM, Jeff Squyres (jsquyres) wrote:
> > On Mar 26, 2013, at 12:16 PM, Bill Long <longb at cray.com> wrote:
> >
> >> I don't think there is a problem. To accommodate -i8 you have to
> >> recompile the MPI module with the -i8 flag set. We've been shipping
> >> two mpi modules as long as I can remember; the compiler scripts
> >> pick the right one based on how the user code is compiled. Same as
> >> how we select the right version of other libraries that also have
> >> Fortran default type arguments. Within the MPI module source the
> >> values of MPI_INTEGER and the similar data types for other Fortran
> >> default types are set based on detection of the actual sizes of the
> >> default types (which change with the compiler options). If you are
> >> using the module compiled with -i8, MPI_INTEGER will encode the
> >> information for an 8-byte integer.
> >
> >
> > But not all Fortran types have corresponding C types (from a
> > standards/strict perspective), right? (e.g., logical -- and I'm not
> > sure about the various complex types...?) So the MPI implementation
> > needs to know that it has to create some synthetic / "good enough"
> > MPI datatypes based on actual Fortran types.
> >
> > ...at least, that's what OMPI does...
>
> What I did was less sophisticated (at least in terms of mpich
> internals). The values for the various handles at page 666 (how
> appropriate) lines 5-10, and 34, and page 667 lines 15-17 are not new.
> I took the values out of the mpich mpif.h files generated for 32-bit
> defaults and 64-bit defaults. Those values are assigned to internal
> constants in the module. The definition of MPI_INTEGER selects between
> the two options depending on KIND(0), and similarly for the others.
> The
> goal is to produce the same values in the module as in the mpif.h
> files,
> only automatically selected based on the default type size specified
> by
> the compiler options used to compile the module.
>
> Cheers,
> Bill
>
>
>
> >
>
> --
> Bill Long longb at cray.com
> Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
--
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)
More information about the mpiwg-fortran
mailing list