On Dec 8, 2015, at 7:02 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote:
> On Dec 8, 2015, at 2:44 PM, Bill Long <longb(a)cray.com> wrote:
>>
>>
>>> 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.
>>
>> How do you handle MPI_SHORT_INT? A short immediately followed in memory by an int will cause the int to have bad memory alignment.
>
> Right. MPI knows this; MPI_SHORT_INT will include padding between the SHORT and INT if it needs to.
>
>> Was it the case that the starting point for the rules was the SEQUENCE type in Fortran (which might have been the only option at the time) and then force C to conform? Today it is easier to get Fortran to mimic what is natural for C.
>
> There are two issues here:
>
> 1. The "good" MPI datatype name of MPI_2INTEGER is already being used; it currently means "INTEGER foo(2)". We want to update it to mean a derived type that contains 2 INTEGERs and still be able to use the MPI datatype name "MPI_2INTEGER" without breaking existing codes.
As I understand the high-level situation, this is all for MPI_REDUCE and friends, and MPI_2INTEGER and MPI_MINLOC or MPI_MAXLOC are all just magic constants that the MPI_REDUCE routine internally decodes to determine what to do. The actual data, the in and out arguments of MPI_REDUCE, are choice arguments (void *).
Current codes have the actual argument IN declared as INTEGER :: IN (2, K) where K is the number of things in the list to be reduced. IN(1,*) is the “VAL" value, and IN(2,*) is the “LOC” value. Since the corresponding dummy argument is (void *) you can pass any actual type, since only the memory layout matters.
>
> I hear you that SEQUENCE is considered bad programming/style. Is having the equivalence between INTEGER foo(2) and a derived type with 2 INTEGERs do-able without using SEQUENCE?
If the above is correct, then the following declarations would have the same memory layouts for the actual arguments:
INTEGER :: IN(2, K)
and
TYPE MPI_2INTEGER_TYPE
SEQUENCE
INTEGER :: VAL
INTEGER :: LOC
END TYPE
TYPE(MPI_2INTEGER_TYPE) :: IN(K)
This seems like sugar coating for the 2INTEGER case.
But, the following would likely not be equivalent:
DOUBLE PRECISION :: IN(2, K)
and
TYPE MPI_DOUBLE_INT_TYPE
SEQUENCE
DOUBLE PRECISION :: VAL
INTEGER :: LOC
END TYPE
TYPE(MPI_DOUBLE_INT_TYPE) :: IN(K)
since the IN(1:2, n) section of the current IN array will have 2 doubles, or 16 bytes in most cases. One element of the new IN would have only 12 bytes. If K is > 1, there is potential for trouble. Certainly no guarantee from the Fortran standard.
The standard does require that INTEGER and REAL (both default) as part of a SEQUENCE type are the same size in memory, so the MPI_REAL_INT_TYPE version would seem to be OK.
>
> 2. I wasn't looking to emulate the C types in Fortran -- I think we've had this discussion before. The intent is to have Fortran-native types (that would be natural for Fortran programmers).
I think BIND(C) is “natural” for Fortran programmers these days. This stuff has been around for over a decade. The use of “DOUBLE PRECISION” is far less natural these days. Essentially everyone has switched to REAL(KIND= ) instead. That stuff is 25 years old.
Cheers,
Bill
> I might not have been clear when I said "parity with the C types" -- what I meant was having "Fortran-natural equivalents of the 6 C MPI_Datatypes".
>
> Make sense?
>
> --
> Jeff Squyres
> jsquyres(a)cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long longb(a)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
On Dec 8, 2015, at 2:44 PM, Bill Long <longb(a)cray.com> wrote:
>
>
>> 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.
>
> How do you handle MPI_SHORT_INT? A short immediately followed in memory by an int will cause the int to have bad memory alignment.
Right. MPI knows this; MPI_SHORT_INT will include padding between the SHORT and INT if it needs to.
> Was it the case that the starting point for the rules was the SEQUENCE type in Fortran (which might have been the only option at the time) and then force C to conform? Today it is easier to get Fortran to mimic what is natural for C.
There are two issues here:
1. The "good" MPI datatype name of MPI_2INTEGER is already being used; it currently means "INTEGER foo(2)". We want to update it to mean a derived type that contains 2 INTEGERs and still be able to use the MPI datatype name "MPI_2INTEGER" without breaking existing codes.
I hear you that SEQUENCE is considered bad programming/style. Is having the equivalence between INTEGER foo(2) and a derived type with 2 INTEGERs do-able without using SEQUENCE?
2. I wasn't looking to emulate the C types in Fortran -- I think we've had this discussion before. The intent is to have Fortran-native types (that would be natural for Fortran programmers). I might not have been clear when I said "parity with the C types" -- what I meant was having "Fortran-natural equivalents of the 6 C MPI_Datatypes".
Make sense?
--
Jeff Squyres
jsquyres(a)cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
On Dec 8, 2015, at 4:46 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
>
>
> On Tue, Dec 8, 2015 at 2:31 PM, Craig Rasmusen <rasmus(a)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(a)cray.com> wrote:
>
> On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres(a)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(a)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(a)hlrs.de>
> >>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
> >>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
> >>>> http://jeffhammond.github.io/
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>
> >>> --
> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>
> >> --
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> >
> > --
> > Jeff Squyres
> > jsquyres(a)cisco.com
> > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran(a)lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> Bill Long longb(a)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(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
>
>
> --
> Jeff Hammond
> jeff.science(a)gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long longb(a)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
On Tue, Dec 8, 2015 at 2:31 PM, Craig Rasmusen <rasmus(a)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(a)cray.com> wrote:
>
>>
>> On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres(a)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(a)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(a)hlrs.de>
>> >>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
>> >>>> To: "MPI-WG Fortran working group" <
>> mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
>> >>>> http://jeffhammond.github.io/
>> >>>>
>> >>>> _______________________________________________
>> >>>> mpiwg-fortran mailing list
>> >>>> mpiwg-fortran(a)lists.mpi-forum.org
>> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> mpiwg-fortran mailing list
>> >>>> mpiwg-fortran(a)lists.mpi-forum.org
>> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>> >>>
>> >>> --
>> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
>> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>> >>
>> >> --
>> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
>> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>> >
>> >
>> > --
>> > Jeff Squyres
>> > jsquyres(a)cisco.com
>> > For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> >
>> > _______________________________________________
>> > mpiwg-fortran mailing list
>> > mpiwg-fortran(a)lists.mpi-forum.org
>> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>
>> Bill Long
>> longb(a)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(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>
>
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
--
Jeff Hammond
jeff.science(a)gmail.com
http://jeffhammond.github.io/
On Dec 8, 2015, at 4:31 PM, Craig Rasmusen <rasmus(a)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.
How do you handle MPI_SHORT_INT? A short immediately followed in memory by an int will cause the int to have bad memory alignment.
Was it the case that the starting point for the rules was the SEQUENCE type in Fortran (which might have been the only option at the time) and then force C to conform? Today it is easier to get Fortran to mimic what is natural for C.
>
> 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).
>
Actually SEQUENCE is still part of the Fortran standard. It’s just considered bad programming style.
Cheers,
Bill
> 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(a)cray.com> wrote:
>
> On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres(a)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(a)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(a)hlrs.de>
> >>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
> >>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
> >>>> http://jeffhammond.github.io/
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>
> >>> --
> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>
> >> --
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> >
> > --
> > Jeff Squyres
> > jsquyres(a)cisco.com
> > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran(a)lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> Bill Long longb(a)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(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long longb(a)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
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(a)cray.com> wrote:
>
> On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres(a)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(a)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(a)hlrs.de>
> >>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
> >>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
> >>>> http://jeffhammond.github.io/
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpiwg-fortran mailing list
> >>>> mpiwg-fortran(a)lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>>
> >>> --
> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >>
> >> --
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> >
> > --
> > Jeff Squyres
> > jsquyres(a)cisco.com
> > For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran(a)lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> Bill Long
> longb(a)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(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
On Dec 8, 2015, at 2:13 PM, Jeff Squyres (jsquyres) <jsquyres(a)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(a)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(a)hlrs.de>
>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
>>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
>>>> http://jeffhammond.github.io/
>>>>
>>>> _______________________________________________
>>>> mpiwg-fortran mailing list
>>>> mpiwg-fortran(a)lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpiwg-fortran mailing list
>>>> mpiwg-fortran(a)lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>>
>>> --
>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
>
> --
> Jeff Squyres
> jsquyres(a)cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long longb(a)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
On Dec 8, 2015, at 2:34 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote:
> On Dec 8, 2015, at 12:05 PM, Bill Long <longb(a)cray.com> wrote:
>>
>>> There's a working group here at the form who is investigating the possibility of passing C function argument as a struct that contains a union, perhaps something like this:
>>
>> Not a good idea in my opinion. The whole idea of overlaying memory bits with variables of different types is something that should be limited to low-level system programmers, if even that. They seem to be wanting to do “fake” polymorphism. How would they propose that the callee figure out which of the options to choose, without the infrastructure of “real” polymorphism.
>
> It's a possibility that is being discussed for a generalized MPI err handler (we have 3 different errhandler types right now, and it's actually kinda painful). :-)
>
> It may or not go anywhere, but the point is that they asked me: can we do this in Fortran?
>
>>> struct to_be_passed_as_an_arg {
>>> enum actual_type;
>>> union {
>>> struct {
>>> MPI_Comm comm;
>>> // ... several more members
>>> } comm_stuff;
>>>
>>> struct {
>>> MPI_Win win;
>>> // ... several more members
>>> } win_stuff;
>>>
>>> struct {
>>> MPI_File file;
>>> // ... several more members
>>> } file_stuff;
>>> } obj;
>>> };
>>> -----
>>>
>>> Can we do this in Fortran? If so, how?
>>
>> Not really.
>
> We're bound to the limitations of C -- so we can't do real polymorphism. Hence the use of the union.
>
> Is there any way to do something like this in Fortran?
No. There is no facility for a particular structure component to have more than one type. And the concept is contrary to the basic Fortran focus on type safety. So I think that adding something like this in the future is very unlikely.
Cheers,
Bill
>
>>> Craig suggests that TRANSFER and/or EQUIVALENCE may be helpful here…?
>>
>> TRANSFER is an executable function. It would not appear as part of a type declaration. EQUIVALENCE, apart from being added to the deprecated list, cannot be applied to component declarations of a type.
>>
>> Cheers,
>> Bill
>>
>>
>>>
>>> --
>>> Jeff Squyres
>>> jsquyres(a)cisco.com
>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>> _______________________________________________
>>> mpiwg-fortran mailing list
>>> mpiwg-fortran(a)lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>
>> Bill Long longb(a)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(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
>
> --
> Jeff Squyres
> jsquyres(a)cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
Bill Long longb(a)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
On Dec 8, 2015, at 12:05 PM, Bill Long <longb(a)cray.com> wrote:
>
>> There's a working group here at the form who is investigating the possibility of passing C function argument as a struct that contains a union, perhaps something like this:
>
> Not a good idea in my opinion. The whole idea of overlaying memory bits with variables of different types is something that should be limited to low-level system programmers, if even that. They seem to be wanting to do “fake” polymorphism. How would they propose that the callee figure out which of the options to choose, without the infrastructure of “real” polymorphism.
It's a possibility that is being discussed for a generalized MPI err handler (we have 3 different errhandler types right now, and it's actually kinda painful). :-)
It may or not go anywhere, but the point is that they asked me: can we do this in Fortran?
>> struct to_be_passed_as_an_arg {
>> enum actual_type;
>> union {
>> struct {
>> MPI_Comm comm;
>> // ... several more members
>> } comm_stuff;
>>
>> struct {
>> MPI_Win win;
>> // ... several more members
>> } win_stuff;
>>
>> struct {
>> MPI_File file;
>> // ... several more members
>> } file_stuff;
>> } obj;
>> };
>> -----
>>
>> Can we do this in Fortran? If so, how?
>
> Not really.
We're bound to the limitations of C -- so we can't do real polymorphism. Hence the use of the union.
Is there any way to do something like this in Fortran?
>> Craig suggests that TRANSFER and/or EQUIVALENCE may be helpful here…?
>
> TRANSFER is an executable function. It would not appear as part of a type declaration. EQUIVALENCE, apart from being added to the deprecated list, cannot be applied to component declarations of a type.
>
> Cheers,
> Bill
>
>
>>
>> --
>> Jeff Squyres
>> jsquyres(a)cisco.com
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> mpiwg-fortran mailing list
>> mpiwg-fortran(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> Bill Long longb(a)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(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
--
Jeff Squyres
jsquyres(a)cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
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
-----
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
-----
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
INTEGER LOC
END TYPE
-----
These 3 new Fortran types would then make Fortran support the same types as C.
3. Deprecate the 2 old MPI datatypes that we don't want to encourage use of anymore:
-----
MPI_2REAL
MPI_2DOUBLE_PRECISION
-----
Thoughts?
> On Dec 8, 2015, at 10:31 AM, Rolf Rabenseifner <rabenseifner(a)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(a)hlrs.de>
>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)cas.uoregon.edu>
>>> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)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(a)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(a)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(a)gmail.com
>>> http://jeffhammond.github.io/
>>>
>>> _______________________________________________
>>> mpiwg-fortran mailing list
>>> mpiwg-fortran(a)lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>>
>>>
>>>
>>> _______________________________________________
>>> mpiwg-fortran mailing list
>>> mpiwg-fortran(a)lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> --
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
--
Jeff Squyres
jsquyres(a)cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
