[MPIWG Fortran] F08 and pair types?

Jeff Hammond jeff.science at gmail.com
Tue Dec 8 16:46:35 CST 2015


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


> 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).
>
>
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20151208/baec9925/attachment-0001.html>


More information about the mpiwg-fortran mailing list