December 2015 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] F08 and pair types?
by Bill Long 08 Dec '15

08 Dec '15

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

1 0

Re: [MPIWG Fortran] F08 and pair types?
by Jeff Hammond 08 Dec '15

08 Dec '15

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/

1 0

Re: [MPIWG Fortran] F08 and pair types?
by Bill Long 08 Dec '15

08 Dec '15

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

1 0

Re: [MPIWG Fortran] F08 and pair types?
by Craig Rasmusen 08 Dec '15

08 Dec '15

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 >

1 0

Re: [MPIWG Fortran] F08 and pair types?
by Bill Long 08 Dec '15

08 Dec '15

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

1 0

Re: [MPIWG Fortran] New question
by Bill Long 08 Dec '15

08 Dec '15

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

1 0

Re: [MPIWG Fortran] New question
by Jeff Squyres (jsquyres) 08 Dec '15

08 Dec '15

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/

1 0

Re: [MPIWG Fortran] F08 and pair types?
by Jeff Squyres (jsquyres) 08 Dec '15

08 Dec '15

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/

1 0

Re: [MPIWG Fortran] New question
by Bill Long 08 Dec '15

08 Dec '15

On Dec 8, 2015, at 1:54 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.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. > > ----- > 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. > > 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

1 0

New question
by Jeff Squyres (jsquyres) 08 Dec '15

08 Dec '15

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: ----- 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? Craig suggests that TRANSFER and/or EQUIVALENCE may be helpful here...? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0