[MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
Bill Long
longb at cray.com
Wed Mar 20 13:15:17 CDT 2013
Hi Rolf,
This looks like good progress toward a solution. There is one missing
piece that I think is needed. If the tools target only the C functions,
then the names of the versions of the C functions that take a choice/buf
argument that is a pointer to a descriptor need to be standardized.
For the moment I'm using MPI_Send_cdesc as the companion of MPI_Send.
Besides the spelling of the function name, only the specification for
the buf argument is changed - all the other arguments and the return
type are the same as for MPI_Send. Since this is a simple replacement
pattern, we would need only a paragraph to describe the naming rule, and
not a complete list of the new prototypes. The actual form of the name
modification is certainly open for discussion. I picked appending
"_cdesc" because the new argument declaration is CFI_cdesc_t, so it
seemed like it would be easy to remember.
Because of the way these descriptors work, the routines that implement
operations like MPI_Send that use a descriptor have to be written in C
anyway. If the interfaces is otherwise the same as for the traditional
MPI_Send then the tools packages would have a much easier time (no
INTEGER or LOGICAL Fortran issues).
For the case of thin Fortran wrappers without BIND(C) and tools looking
at the C functions only, these names would be required. For other
implementation options, it is not as clear if it is necessary to require
these C function names. However, if they were required universally,
then C programmers would have the option of calling these functions
directly, which would seem like a nice facility for them, particularly
where performance is an issue.
Cheers,
Bill
On 3/20/13 12:09 PM, Rolf Rabenseifner wrote:
> This mail contains a proposal how we can solve the current
> Fortran problems and possibly making the tools people also happy.
>
> I need at least answers for
> - mpich (Bill Long),
> - OpenMPI (Jeff or Craig),
> - some tools people.
>
> Let me summarize what I've learnt so far for mpi_f08:
>
> - #364 about LOGICAL correction is a must.
> - MPI-3.0 allows BIND(C) and non-BIND(C), with the
> new restrictions in #364
> - BIND(C) needs TR29113, therefore any implementation now
> should use non-BIND(C) for all non-TR29113 compilers.
> - Most (or all) try to use the non-BIND(C) interface.
> - Best way to do this are thin wrappers in Fortran that
> internally call
> - the oficial MPI-3.0 C binding
> (here, the tools people have a problem because they
> expect to wrap the Fortran interface and may therefore
> double-wrap), or
> - or an internal MPI-3.0 C routine
> (which is half-perfect for the tools folk, because
> they have to handle the implementation-dependant
> Fortran names with underscores).
> - And at least Bill wants to include the Fortran MPI
> library routines itselves in the mpi_f08 module.
> This is in conflict with the current MPI-3.0
> linker naming rules.
>
> Implications and proposal:
> - We should rewrite the linker names section MPI-3.0 17.1.5
> with following goals:
> - Allow additionally to define that the PMPI is provided
> only on the MPI C interface and the Fortran MPI routines
> internally call the C interface;
> again, a macro definition in mpi.h tells whether this
> is chosen.
> Question: Would this cause a problem when linking a
> C or Fortran user application with some own
> MPI_Test etc. profiling routines that internally call
> PMPI_Test?
> - If Fortran profiling is done through the MPI C binding
> then there are no rules about the Fortran linker names
> needed, and therefore, one may put the thin Fortran
> wrappers into a Fortran module.
> - We can define BIND(C) for MPI routine groups as a
> future option that is currently not used.
> This would reduce the current effort for the tools people.
> Is there anybody who wants to implement one of the Fortran
> routine groups with BIND(C)?
>
> I would expect, that this is the best to solve the problem
> that #364 prohibits BIND(C) for some routines and implementors
> want to do the same method for all routines.
>
> Don't forget that BIND(C) and TR29113 is still important
> for implementing these thin wrappers internally.
>
> Without using BIND(C) on the official mpi_f08 and mpi module
> interface, some features of TR29113 are not used:
> - the extension for interoperabple CHARACTER(LEN=*),
> - the extension for OPTIONAL dummy arguments.
>
> Other TR29113 features are heavily used:
> - The DIMENSION(..), TYPE(*) is needed for some internal
> C-written MPI_Isend_desc.
> - The ASYNCHRONOUS usage for communication buffers.
>
> Should we go in this direction?
>
> Best regards
> Rolf
>
>
> ----- Original Message -----
>> From: "Bill Long" <longb at cray.com>
>> To: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
>> Cc: "Martin Schulz" <schulzm at llnl.gov>, "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>
>> Sent: Wednesday, March 20, 2013 4:01:52 PM
>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
>> On 3/20/13 8:26 AM, Jeff Squyres (jsquyres) wrote:
>>> On Mar 20, 2013, at 6:25 AM, Bill Long <longb at cray.com> wrote:
>>>
>>>> interface !--> MPI_Test
>>>>
>>>> ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status
>>>> *status);
>>>>
>>>> Function MPI_Test_C( request, flag, status) &
>>>> BIND(C, name="MPI_Test") RESULT (res)
>>>> import :: C_request, c_int, MPI_Status_C
>>>> integer(C_request) :: request
>>>
>>> This is not correct. You cannot assume that MPI handles are integers
>>> (they're pointers in Open MPI).
>>
>>
>> This is correct for mpich. OpenMPI would evidently have a different
>> version. But the concept is still the same - make a correct interface
>> to the C library routine, however it is defined by the implementation,
>> and then call that from a thin Fortran wrapper that takes care of the
>> issues related to LOGICAL, the use of default INTEGER, and OPTIONAL
>> arguments.
>>
>> 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
>>
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
--
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
More information about the mpiwg-fortran
mailing list