[MPIWG Fortran] F08 and pair types?

Bill Long longb at cray.com
Tue Dec 8 17:17:48 CST 2015 

On Dec 8, 2015, at 4:46 PM, Jeff Hammond <jeff.science at gmail.com> wrote:

> 
> 
> On Tue, Dec 8, 2015 at 2:31 PM, Craig Rasmusen <rasmus at cas.uoregon.edu> wrote:
> Bill,
> 
> I was about to suggest the possibility of using BIND(C) for the other types, e.g., MPI_REAL_INTEGER_TYPE but Jeff pointed out to me this morning that MPI_FLOAT_INT are not really C structs.  The MPI standard reads
> 
> "The datatype MPI_FLOAT_INT is as if defined by the following ..."
> 
> and goes on to define an MPI Datatype that is a C float followed immediately in memory by a C int.  So the MPI standard actually defines a memory representation rather than a C struct.
> 
> 

Jeff H. replies:

> Which is good, because if it was defined in terms of C struct, then the MPI library would have to know how the C compiler handled padding.

In the abstract, perhaps a valid point.  However,  various system header files contain C struct definitions and arguments of those types are sent to system C library routines.  If Brand X C compiler disagrees with gcc about the layout of simple structs, your program execution is probably not going to get far enough to call an MPI routine. Basically, at least in the Unix/Linux universe (where multiple compiler vendors are common) everyone needs to conform to the padding rules used by the compiler used to compile the OS and system libraries (i.e. gcc).  So, I don’t think there is an issue here as long as the MPI library routines have formal parameters with the same struct types. Which could/should be supplied in mpi.h so all the C compilations see the same thing. 

>  
> Thus SEQUENCE is really what Jeff wants although I just checked the Fortran standard and SEQUENCE really looks to be archaic (removed from the standard).
> 

If the MPI library routines have formal parameters of the “obvious” struct types, then the guaranteed solution for Fortran is to defined derived types with exactly the same padding rules.  That is, make them BIND(C) types, and not SEQUENCE types. 

Cheers,
Bill



> 
> Hammond vs Squyres is important to clarify in this thread.
>  
> It seems to me that the MPI standard shouldn't use features that are no longer in the Fortran standard.  So I no longer can think of an effective way to use this feature of the MPI standard.
> 
> My question to Jeff:  How do C users use this facility (or even how do you implement it)?  Specifically, a C struct doesn't define the representation in memory of the data members (although is does define the order).  According to the C standard:
> 
> "Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type."
> 
> and is thus free to add padding.  So how in C can you legally implement and use MPI_FLOAT_INT?  The only way I can think of is to use memory offsets and cast the resulting address.  Not really pretty code but at least legal.
> 
> -craig
> 
> On Tue, Dec 8, 2015 at 1:14 PM, Bill Long <longb at cray.com> wrote:
> 
> On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
> > We talked about this in detail at the SJC meeting this morning.
> >
> > 1. In MPI 3.1 section 5.9.4 p180, the following types are defined for fortran:
> >
> > -----
> > MPI_2REAL
> > MPI_2DOUBLE_PRECISION
> > MPI_2INTEGER
> > -----
> >
> > The following types are defined for C:
> >
> > -----
> > MPI_FLOAT_INT
> > MPI_DOUBLE_INT
> > MPI_LONG_INT
> > MPI_2INT
> > MPI_SHORT_INT
> > MPI_LONG_DOUBLE_INT
> > ——
> 
> 
> I assume the C versions are structs with two members of the obvious types.  One could mimic these in Fortran:
> 
> use,intrinsic :: iso_c_binding
> 
> type,bind(c) :: mpi_float_int   ! the bind(c) ensures the C compiler’s memory layout
>    real(c_float) ::  val
>    integer(c_int) :: loc
> end type
> 
> and facilitate calling the C routines directly.
> 
> When you say REAL , DOUBLE PRECISION, and INTEGER, do you mean the “default” ones.  I.e. the ones with a bit-size that can depend on compiler options?   That complicates things, combinatorially if the compile specifies -r8, -i4, for example.
> 
> 
> >
> > 2. What Jeff Hammond asks is quite reasonable; it seems like we should use the Fortran derived types for MINLOC and MAXLOC functionality.  The old Fortran types (2REAL, 2DOUBLE_PRECISION, 2INTEGER) exist because there were no derived types back in the early 90's.
> >
> > I think we can make three proposals (NOTE: we need to cross reference these proposals with the RMA and collective working groups, but I want to get the Fortran stuff correct first):
> >
> > 2a. Change the definition of MPI_INTEGER from
> >
> > -----
> > INTEGER FOO(2)
> > -----
> >
> > to (please correct my fortran syntax; you all know I have some of it wrong below...)
> >
> > ------
> > TYPE :: MPI_2INTEGER_TYPE, SEQUENCE
> >    INTEGER VAL
> >    INTEGER LOC
> > END TYPE
> > ——
> 
> 
> This syntax would be
> 
> TYPE :: MPI_2INTEGER_TYPE
>     SEQUENCE
>     NTEGER VAL
>    INTEGER LOC
> END TYPE
> 
> 
> However, apart from using default types, most Fortran gurus would be revolted at the use of the archaic SEQUENCE specification.  This is something that should already have been on the MPI deprecated list.
> 
> 
> 
> >
> > Craig assures me that these two Fortran types are exactly the same in memory representation.  Hence, even though we're technically changing the back-end representation of MPI_2INTEGER, we're changing it to an exactly equivalent definition.  Hence, old codes will not break -- we're just updating to use newer Fortran syntax.
> >
> > Also, create two new types:
> >
> > -----
> > TYPE :: MPI_REAL_INTEGER_TYPE, SEQUENCE
> >    REAL VAL
> >    INTEGER LOC
> > END TYPE
> >
> > TYPE :: MPI_DOUBLE_PRECISION_INTEGER_TYPE, SEQUENCE
> >    DOUBLE PRECISION VAL
> >    INTEGER LOC
> > END TYPE
> > -----
> >
> > And MPI datatypes corresponding to these two new types: MPI_REAL_INTEGER, MPI_DOUBLE_PRECISION_INTEGER
> >
> > Note: with this one old type (2INTEGER) and the 2 new types (REAL_INTEGER and DOUBLE_PRECISION_INTEGER) correspond to the C types MPI_2INT, MPI_FLOAT_INT, MPI_DOUBLE_INT, respectively.
> >
> > 2b. Create three additional new Fortran types to make parity with the remaining C types (MPI_LONG_INT, MPI_SHORT_INT, MPI_LONG_DOUBLE_INT) -- the names below are completely up for negotiation, and may even be longer than 31 characters:
> >
> > -----
> > TYPE :: MPI_LONGINTEGER_INTEGER_TYPE, SEQUENCE
> >    INTEGER(KIND=whatever) VAL
> >    INTEGER LOC
> > END TYPE
> >
> > TYPE :: MPI_SHORTINTEGER_INTEGER_TYPE, SEQUENCE
> >    INTEGER(KIND=whatever) VAL
> >    INTEGER LOC
> > END TYPE
> >
> > TYPE :: MPI_QUAD_PRECISION_INTEGER_TYPE, SEQUENCE
> >    DOUBLE PRECISION(KIND=whatever) VAL
> 
> REAL(KIND=whatever) VAL
> 
> The single, double, and quad versions would be identical except for the values for “whatever”.
> 
> 
> >    INTEGER LOC
> > END TYPE
> > -----
> >
> > These 3 new Fortran types would then make Fortran support the same types as C.
> 
> I would recommend use of the bind(c) types instead, as illustrated above, if you want to duplicate the C types.
> 
> >
> > 3. Deprecate the 2 old MPI datatypes that we don't want to encourage use of anymore:
> >
> > -----
> > MPI_2REAL
> > MPI_2DOUBLE_PRECISION
> 
> Seems like a good idea.
> 
> Cheers,
> Bill
> 
> > -----
> >
> > Thoughts?
> >
> >
> >
> >> On Dec 8, 2015, at 10:31 AM, Rolf Rabenseifner <rabenseifner at hlrs.de> wrote:
> >>
> >> Sorry, but I was too fast with my negative answer.
> >> Yes, we have both arguments in the reduction
> >> and therefore it would be simple to add a new
> >> datatype to the list of allowed datatypes for
> >> MIN/MAXLOC in Fortran.
> >>
> >> Deprecation is too expensive and there is no need.
> >>
> >> Rolf
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> >>> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> >>> Sent: Tuesday, December 8, 2015 7:22:45 PM
> >>> Subject: Re: [MPIWG Fortran] F08 and pair types?
> >>
> >>> I'm sorry, but I expect that deprecation of a language binding
> >>> is not possible for a feature that is still valid in other languages (here C).
> >>>
> >>> This means, that MINLOC and MAXLOC are as they are defined
> >>> and there is no reason to deprecate them.
> >>> They are not wrong and nobody want to pay the maintenance costs
> >>> for modifying existing applications that use MIN/MAXLOC.
> >>>
> >>> The only way to do it better, is to add a new feature, e.g.,
> >>> MINLOC_F08 and MAXLOC_F08 which is valid only for the new
> >>> mpi_f08 module.
> >>>
> >>> Rolf
> >>>
> >>> ----- Original Message -----
> >>>> From: "Craig Rasmussen" <rasmus at cas.uoregon.edu>
> >>>> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
> >>>> Sent: Tuesday, December 8, 2015 6:30:37 PM
> >>>> Subject: Re: [MPIWG Fortran] F08 and pair types?
> >>>
> >>>> The old stuff could be deprecated because all existing compilers that I know of
> >>>> support user-defined types. I assume that "deprecated" means that it still
> >>>> exists in libraries for legacy apps but is no longer really defined in the
> >>>> standard.
> >>>>
> >>>> -craig
> >>>>
> >>>> On Tue, Dec 8, 2015 at 9:19 AM, Craig Rasmusen < rasmus at cas.uoregon.edu > wrote:
> >>>>
> >>>>
> >>>>
> >>>> Fortran is a modern language? Wut...
> >>>>
> >>>> Actually seems like a simple and good change. For example, could define:
> >>>>
> >>>> MPI_REAL_INT and MPI_INTEGER_INT
> >>>>
> >>>> However, I'm not sure what would be in the structs (user-defined types). I'll
> >>>> have to ask Squyres what the text following
> >>>>
> >>>> "The datatype MPI_FLOAT_INT is as if defined by the following sequence of
> >>>> instructions"
> >>>>
> >>>> means.
> >>>>
> >>>> -craig
> >>>>
> >>>> On Mon, Dec 7, 2015 at 4:20 PM, Jeff Hammond < jeff.science at gmail.com > wrote:
> >>>>
> >>>>
> >>>>
> >>>> I have a reasonable understanding of why the legacy Fortran bindings use 2REAL,
> >>>> 2DOUBLE_PRECISION and 2INTEGER with {MAX,MIN}LOC reductions.
> >>>>
> >>>> Doesn't modern Fortran provide a way to create struct-like things along the
> >>>> lines of C, such that more appropriate pair types could be used for these?
> >>>>
> >>>> The relevant text is section 5.9.4 of MPI 3.1.
> >>>>
> >>>> Jeff
> >>>>
> >>>> --
> >>>> Jeff Hammond
> >>>> jeff.science at gmail.com
> >>>> http://jeffhammond.github.io/
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran at lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran at lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: Room 1.307)
> >>> _______________________________________________
> >>> mpiwg-fortran mailing list
> >>> mpiwg-fortran at lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: Room 1.307)
> >> _______________________________________________
> >> mpiwg-fortran mailing list
> >> mpiwg-fortran at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> >
> > --
> > Jeff Squyres
> > jsquyres at cisco.com
> > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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
> 
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> 
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> 
> 
> 
> -- 
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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