[MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind

Craig Rasmussen rasmus at cas.uoregon.edu
Wed Mar 27 17:42:05 CDT 2013

Rolf, I'm sorry to say this but it all seems way too complicated to me.  There are too many subgroups, options, special cases, ...  When things are too complicated, usually this means that something is wrong.

Therefore I vote for new option 2x:

There is a problem with the PMPI interfaces for MPI-3 in Fortran.  Therefore as an erratum, we pull them from the standard and fix things up in MPI 3.1/4.0.  This means that the BIND(C) names are removed AND they are not replaced by anything in the erratum.

I'm of the strong opinion that while you CAN remove something that is broken in an erratum, you CAN'T replace the old names with a complete hash of NEW names that will be placed in the MPI namespace forever.  Furthermore, these proposed NEW names are completely outside of any language standard and will place too many restrictions on how the MPI 3.0 standard must be implemented.  For example, you have to be very careful in how you implement the new names, otherwise an aggressive compiler will optimize the calls away and the proposed NEW, NON-STANDARD symbol names, will disappear (i.e., they will never be called).

I plan on attending the next MPI meeting in June to discuss these issues in front of the full MPI Forum.

Craig Rasmussen
CAS Scientific Programmer
rasmus at cas.uoregon.edu

On Mar 27, 2013, at 11:57 AM, Rolf Rabenseifner wrote:

> 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 
>  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) 
>  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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20130327/6f489145/attachment-0001.html>

More information about the mpiwg-fortran mailing list