February 2016 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Hammond 18 Feb '16

18 Feb '16

The only reasonable thing to do here is to include MPI_INTEGER and other Fortran datatype enumerations in the meaning of Fortran bindings and not define them in the absence of a Fortran compiler. Any other solution is unreliable, ill-defined and going to lead to sadness. More below. On Thu, Feb 18, 2016 at 3:45 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > A question has come up recently in the Open MPI community (being debated in a lengthy thread here https://www.open-mpi.org/community/lists/users/2016/02/28448.php) > > If Fortran support is not provided in an Open MPI installation (e.g., if Open MPI's configure script detects that there is no Fortran compiler, and therefore none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran datatypes (e.g., MPI_INTEGER) be available in the C bindings? > > It was pointed out that MPI-3.1 says that the Fortran bindings are optional -- but datatypes are not currently marked as optional. > > Hence, even if you don't have to Fortran compiler, you still have to have declarations for MPI_INTEGER (and friends) in mpi.h. > > What do people think about this? > > ARGUMENTS FOR KEEPING IT THE SAME > ================================= > > A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL. I will repeat what I said on the Open-MPI list. THIS IS HORRIBLE. It delays the failure until runtime. There is absolutely no value whatsoever in allowing a successful build of an application that is going to crash and burn the moment it touches this datatype, particularly in light of our discussion about a month ago regarding when MPI_DATATYPE_NULL can be used (basically never). I do not want MPI implementations to lie to build systems about the availability of MPI_INTEGER in C when it is not actually a functional feature. Additional reasons: Jed Brown. PETSc. <<< This is here for Jed's email filters. > A2. MPI could probably figure out what Fortran INTEGER would have been (i.e., probably equivalent to C int) and just set MPI_INTEGER to be that. This is also horrible, because Fortran INTEGER does not have fixed width. Here is what ISO Fortran 2008 says about INTEGER: "The processor shall provide at least one representation method with a decimal exponent range greater than or equal to 18." Please explain the unambiguous mapping between this definition and the definition of ISO C int. > > A3. The whole point of having Fortran datatypes available in C is that even an MPI process written in C can receive/send data from MPI processes in Fortran. Hence, *this* MPI process -- compiled by an MPI implementation that does not have a Fortran compiler -- may not have Fortran support, but a peer MPI process in the same MPI job may have Fortran support. Such a process cannot send or receive Fortran INTEGER data because it has no idea the size of such data. This sort of use case is best supported by sending and receiving the data as bytes, because the no-Fortran process can understand that. Alternatively, the Fortran processes can use ISO_C_BINDING and convert to C datatypes before sending. Since we have standardized the use of Fortran 2008 in MPI-3, there is absolutely no reason why this should not be the recommended practice, because it is completely reliable and well-defined. > ARGUMENTS FOR A CHANGE > ====================== > > B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a run-time MPI exception -- is somewhat anti-social behavior (and potentially confusing to the user). See above. > B2. An MPI implementation can *assume* but can't *know* what the size/representation of Fortran datatypes are unless there's a Fortran compiler with which to test. You know what happens when you assume, right? What possible value does it serve to guess? We create a situation where sometimes it works and sometimes MPI programs crash and burn? While we are at it, let's add MPI_Barrier_sometimes(double randomness_factor)... > B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but fairly uncommon to have multiple MPI implementation installations involved in a single execution of an MPI application. It is valid to have multiple implementations, but not valid to expect processes that use a Fortran-oblivious MPI library to understand Fortran data. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Hammond 18 Feb '16

18 Feb '16

On Thu, Feb 18, 2016 at 5:58 AM, Bill Long <longb(a)cray.com> wrote: > > It would seem peculiar to have no Fortran compiler installed. Even if > that was the case at the moment, it could change in the future, and you > would not want to have to rebuild MPI in that case. > It is not peculiar. LLVM does not yet have a usable Fortran front-end, so anyone that uses this compiler toolchain exclusively does not have a Fortran compiler. When I build MPICH with LLVM, I do a pure build, wherein CC=clang, CXX=clang++ FC=false. This means that my MPI library cannot know anything about Fortran and I do not want it to make stuff up. LLVM is the system compiler for a relatively large computer company known as Apple, and many HPC users own such systems :-) Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Rolf Rabenseifner 18 Feb '16

18 Feb '16

I'm sure that I cannot oversee the whole problem in the moment, therefore my proposal may be not good enough, but it is very simple. I would propose to add an advice to implementers to the standard (e.g., after the first sentence of page 659 line 2) in the way: In the case of a missing accompanying Fortran compiler, a high-quality MPI implementation would provide the Fortran datatypes with sizes based on Table 13.2 on page 540 and alignments that are a identical to the size (single unit size x in case of 2*x), but not larger than 4. (As far as I remenber, this is the standard or usual Fortran alignment for common blocks and SEQUENCEd derived Fortran types, if a numerical unit is 4 bytes, which is used as the basis in Table 13.2) I hope, that this helpes and reduces any complication that applications may have when - not providing the Fortran datatypes, or - providing them as MPI_DATAYPE_NULL. Rolf ----- Original Message ----- > From: "longb" <longb(a)cray.com> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Thursday, February 18, 2016 2:58:54 PM > Subject: Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided? > On Feb 18, 2016, at 5:45 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> A question has come up recently in the Open MPI community (being debated in a >> lengthy thread here >> https://www.open-mpi.org/community/lists/users/2016/02/28448.php) >> >> If Fortran support is not provided in an Open MPI installation (e.g., if Open >> MPI's configure script detects that there is no Fortran compiler, and therefore >> none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran >> datatypes (e.g., MPI_INTEGER) be available in the C bindings? > > > This argument seems shortsighted. > > It would seem peculiar to have no Fortran compiler installed. Even if that was > the case at the moment, it could change in the future, and you would not want > to have to rebuild MPI in that case. > > What about MPI I/O? Even if the local system that is writing a file does not > have a Fortran compiler, the program (on a different system) reading the file > might, and be expecting Fortran data types to have been used in writing the > file. > > >> >> It was pointed out that MPI-3.1 says that the Fortran bindings are optional -- >> but datatypes are not currently marked as optional. >> >> Hence, even if you don't have to Fortran compiler, you still have to have >> declarations for MPI_INTEGER (and friends) in mpi.h. >> >> What do people think about this? >> >> ARGUMENTS FOR KEEPING IT THE SAME >> ================================= >> >> A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL. > > I agree with B1 in this case - this is unnecessarily hostile. > >> A2. MPI could probably figure out what Fortran INTEGER would have been (i.e., >> probably equivalent to C int) and just set MPI_INTEGER to be that. > > Instead, the spec might be more specific in this case. If there is no Fortran > information available, specify a default mapping, such as INTEGER -> int, REAL > -> float, … A sampling of existing Fortran and C compilers that are designed > to interoperate would probably lead to a pretty universal set of mappings > (ignoring the -r8 -i8 issue noted below). > >> A3. The whole point of having Fortran datatypes available in C is that even an >> MPI process written in C can receive/send data from MPI processes in Fortran. >> Hence, *this* MPI process -- compiled by an MPI implementation that does not >> have a Fortran compiler -- may not have Fortran support, but a peer MPI process >> in the same MPI job may have Fortran support. > > I think the MPI I/O argument might be a stronger case for A3. > >> >> ARGUMENTS FOR A CHANGE >> ====================== >> >> B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a >> run-time MPI exception -- is somewhat anti-social behavior (and potentially >> confusing to the user). > > Agree. But coming up with a bad idea is not a convincing argument for a change. > >> B2. An MPI implementation can *assume* but can't *know* what the >> size/representation of Fortran datatypes are unless there's a Fortran compiler >> with which to test. > > Even in that case, you can’t know for sure because (too many) Fortran compilers > have command line switches like -r8 or -i8 that change, on a program by program > basis, what REAL or INTEGER means. > >> B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but >> fairly uncommon to have multiple MPI implementation installations involved in a >> single execution of an MPI application. > > I agree with this, but the MPI I/O example does not involve a single execution. > > 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 -- 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)

1 0

Re: [MPIWG Fortran] Provide Fortran datatypes if Fortran bindings not provided?
by Bill Long 18 Feb '16

18 Feb '16

On Feb 18, 2016, at 5:45 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > A question has come up recently in the Open MPI community (being debated in a lengthy thread here https://www.open-mpi.org/community/lists/users/2016/02/28448.php) > > If Fortran support is not provided in an Open MPI installation (e.g., if Open MPI's configure script detects that there is no Fortran compiler, and therefore none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran datatypes (e.g., MPI_INTEGER) be available in the C bindings? This argument seems shortsighted. It would seem peculiar to have no Fortran compiler installed. Even if that was the case at the moment, it could change in the future, and you would not want to have to rebuild MPI in that case. What about MPI I/O? Even if the local system that is writing a file does not have a Fortran compiler, the program (on a different system) reading the file might, and be expecting Fortran data types to have been used in writing the file. > > It was pointed out that MPI-3.1 says that the Fortran bindings are optional -- but datatypes are not currently marked as optional. > > Hence, even if you don't have to Fortran compiler, you still have to have declarations for MPI_INTEGER (and friends) in mpi.h. > > What do people think about this? > > ARGUMENTS FOR KEEPING IT THE SAME > ================================= > > A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL. I agree with B1 in this case - this is unnecessarily hostile. > A2. MPI could probably figure out what Fortran INTEGER would have been (i.e., probably equivalent to C int) and just set MPI_INTEGER to be that. Instead, the spec might be more specific in this case. If there is no Fortran information available, specify a default mapping, such as INTEGER -> int, REAL -> float, … A sampling of existing Fortran and C compilers that are designed to interoperate would probably lead to a pretty universal set of mappings (ignoring the -r8 -i8 issue noted below). > A3. The whole point of having Fortran datatypes available in C is that even an MPI process written in C can receive/send data from MPI processes in Fortran. Hence, *this* MPI process -- compiled by an MPI implementation that does not have a Fortran compiler -- may not have Fortran support, but a peer MPI process in the same MPI job may have Fortran support. I think the MPI I/O argument might be a stronger case for A3. > > ARGUMENTS FOR A CHANGE > ====================== > > B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a run-time MPI exception -- is somewhat anti-social behavior (and potentially confusing to the user). Agree. But coming up with a bad idea is not a convincing argument for a change. > B2. An MPI implementation can *assume* but can't *know* what the size/representation of Fortran datatypes are unless there's a Fortran compiler with which to test. Even in that case, you can’t know for sure because (too many) Fortran compilers have command line switches like -r8 or -i8 that change, on a program by program basis, what REAL or INTEGER means. > B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but fairly uncommon to have multiple MPI implementation installations involved in a single execution of an MPI application. I agree with this, but the MPI I/O example does not involve a single execution. 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

Provide Fortran datatypes if Fortran bindings not provided?
by Jeff Squyres (jsquyres) 18 Feb '16

18 Feb '16

A question has come up recently in the Open MPI community (being debated in a lengthy thread here https://www.open-mpi.org/community/lists/users/2016/02/28448.php) If Fortran support is not provided in an Open MPI installation (e.g., if Open MPI's configure script detects that there is no Fortran compiler, and therefore none of the mpif.h, mpi module, or mpi_f08 module are compiled), should Fortran datatypes (e.g., MPI_INTEGER) be available in the C bindings? It was pointed out that MPI-3.1 says that the Fortran bindings are optional -- but datatypes are not currently marked as optional. Hence, even if you don't have to Fortran compiler, you still have to have declarations for MPI_INTEGER (and friends) in mpi.h. What do people think about this? ARGUMENTS FOR KEEPING IT THE SAME ================================= A1. MPI can set MPI_INTEGER to be equivalent to MPI_DATATYPE_NULL. A2. MPI could probably figure out what Fortran INTEGER would have been (i.e., probably equivalent to C int) and just set MPI_INTEGER to be that. A3. The whole point of having Fortran datatypes available in C is that even an MPI process written in C can receive/send data from MPI processes in Fortran. Hence, *this* MPI process -- compiled by an MPI implementation that does not have a Fortran compiler -- may not have Fortran support, but a peer MPI process in the same MPI job may have Fortran support. ARGUMENTS FOR A CHANGE ====================== B1. Setting MPI_INTEGER (and friends) to MPI_DATATYPE_NULL -- which will cause a run-time MPI exception -- is somewhat anti-social behavior (and potentially confusing to the user). B2. An MPI implementation can *assume* but can't *know* what the size/representation of Fortran datatypes are unless there's a Fortran compiler with which to test. B3. A3 is a somewhat sketchy claim. It's obviously possible and valid, but fairly uncommon to have multiple MPI implementation installations involved in a single execution of an MPI application. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0