[MPIWG Fortran] F08 and pair types?

Craig Rasmusen rasmus at cas.uoregon.edu
Tue Dec 8 16:31:11 CST 2015


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.

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

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


More information about the mpiwg-fortran mailing list