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

Re: [MPIWG Fortran] MPI Fortran ABI discussion scheduling and agenda
by Jeff Hammond 29 Aug '23

29 Aug '23

Terse minutes from the meeting follow. Please correct the record if I have made an error. Thanks to everyone who attended (I didn't transcript it, but at least Jeff H, Quincy K, Bill W, Bill L, Ken R, Julien J, Joseph S, Christian N, M Klemm, and Abraham N were there). Decision 1: The sizes of Fortran types is part of the MPI ABI and each choice/combination of these requires a separate implementation. The stipulation that the user must use exactly one of these throughout the application extends to the Fortran sizes. Rationale: Every other option is extremely difficult to implement and unpleasant to reason about. If we figure out a more compact way to solve this problem, we can standardize it in the future. The O(n) solution is practical because today no implementation implements n>2. Corollary 1: There is one mpi.h, one libmpi_abi.so and one of each for the Fortran modules (and header, if supported) for every MPI C+Fortran ABI. If an implementation provides more than one MPI C+Fortran ABI, the implementation should distinguish them using paths. Decision 2: The sizes prescribed by the external32 specification are required to be supported in the ABI. All other sets of sizes are optional. Corollary 2: User code must do one of the following: 1. Assume the external32 ABI. If wrong SO is linked, that's a user error and bad things will happen. 2. Query the Fortran size ABI to ensure that the MPI SO matches the Fortran object code, and abort if they don't match. 2. Query the Fortran size ABI to ensure that the MPI SO matches the Fortran object code, and handle any differences manually, e.g. using MPI_INTEGER8 instead of MPI_INTEGER. Corollary 3: MPI_Type_size must be callable before MPI_Init for all predefined datatypes (and only predefined datatypes), because this is how a user can detect potential ABI problems. If people don't like this, then I'll add MPI_Abi_type_sizes that meets the need, without supporting the generality of MPI_Type_size. Jeff On Fri, Aug 25, 2023 at 11:35 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: > We need to meet to discuss some of the open problems with the MPI Fortran > ABI. > > https://www.when2meet.com/?21032099-f9qjp > > The agenda is > https://docs.google.com/document/d/1URUIbHhGQfUcoNg_KTX1lhWS-Z80LwJA9LH2QL7…. > You'll need to request access to comment/edit because this email list is > public and I do not want to deal with vandalism. > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

MPI Fortran ABI discussion - Tuesday at 5 PM EET
by Jeff Hammond 28 Aug '23

28 Aug '23

Based on availability, we will meet tomorrow at 5 PM Helsinki time, which is 10 AM New York time and 7 AM California time. ________________________________________________________________________________ Microsoft Teams meeting Join on your computer, mobile app or room device Click here to join the meeting <https://teams.microsoft.com/l/meetup-join/19%3ameeting_N2FjZDVkOWItMDc4OS00…> Meeting ID: 286 245 066 993 Passcode: SUGbfQ Download Teams <https://www.microsoft.com/en-us/microsoft-teams/download-app> | Join on the web <https://www.microsoft.com/microsoft-teams/join-a-meeting> Join with a video conferencing device teams(a)vc.nvidia.com Video Conference ID: 116 411 016 9 Alternate VTC instructions <https://pexip.me/teams/vc.nvidia.com/1164110169> Or call in (audio only) +1 949-570-1120,,518282305# <+19495701120,,518282305#> United States, Irvine Phone Conference ID: 518 282 305# Find a local number <https://dialin.teams.microsoft.com/c58d41ec-314f-4761-9381-98dfc4066d1b?id=…> | Reset PIN <https://dialin.teams.microsoft.com/usp/pstnconferencing> Learn More <https://aka.ms/JoinTeamsMeeting> | Meeting options <https://teams.microsoft.com/meetingOptions/?organizerId=64532211-6004-4136-…> ________________________________________________________________________________

1 0

Re: [MPIWG Fortran] MPI Fortran ABI discussion scheduling and agenda
by Jeff Hammond 25 Aug '23

25 Aug '23

Yes, you are right, but MPI_DOUBLE_PRECISION is a unique predefined datatype, and we need to understand what size it is, regardless of how it relates to MPI_REAL, MPI_REAL4, MPI_REAL8 or MPI_REAL16. DOUBLE PRECISION and MPI_DOUBLE_PRECISION are the least of my concerns right now. Jeff On Fri, Aug 25, 2023 at 7:16 PM Long, Bill F <william.long(a)hpe.com> wrote: > Just a note that DOUBLR PRECISION is not a separate type in Fortran, but > just one of the REAL types: > > 1. > > "The keyword DOUBLE PRECISION is an alternative specifier for one kind > of real type." > > I think that in C float and double are different. > > CHeers, > Bill > > ------------------------------ > *From:* mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> on > behalf of Jeff Hammond via mpiwg-fortran < > mpiwg-fortran(a)lists.mpi-forum.org> > *Sent:* Friday, August 25, 2023 3:35 AM > *To:* mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org>; MPI Forum < > mpiwg-fortran(a)lists.mpi-forum.org> > *Cc:* Jeff Hammond <jeff.science(a)gmail.com> > *Subject:* [MPIWG Fortran] MPI Fortran ABI discussion scheduling and > agenda > > We need to meet to discuss some of the open problems with the MPI Fortran > ABI. > > https://www.when2meet.com/?21032099-f9qjp > > The agenda is > https://docs.google.com/document/d/1URUIbHhGQfUcoNg_KTX1lhWS-Z80LwJA9LH2QL7…. > You'll need to request access to comment/edit because this email list is > public and I do not want to deal with vandalism. > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

MPI Fortran ABI discussion scheduling and agenda
by Jeff Hammond 25 Aug '23

25 Aug '23

We need to meet to discuss some of the open problems with the MPI Fortran ABI. https://www.when2meet.com/?21032099-f9qjp The agenda is https://docs.google.com/document/d/1URUIbHhGQfUcoNg_KTX1lhWS-Z80LwJA9LH2QL7…. You'll need to request access to comment/edit because this email list is public and I do not want to deal with vandalism. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

The problem with that is here: int MPI_Status_c2f(const MPI_Status *c_status, MPI_Fint *f_status) You are right that pass-by-value scalars are fine if we bound the range to make truncation work, but pointers do not allow this. Jeff > On 18. Aug 2023, at 12.45, William Robert Williams <william.williams(a)tu-dresden.de> wrote: > > Is there a reason not to mix 1 and 3: MPI_Fint is a fixed C type, decouple it from INTEGER, and require Fortran handles to stay within the smaller of INTEGER and MPI_Fint in order to be valid? (Yes, backwards compatibility, but that’s probably gone regardless in order to ABI-specify MPI_Fint.) This way an implementation can have larger or smaller INTEGERs vs. C ints as it desires, as long as it guarantees that they are valid MPI_Fints as well, and Fint stays fixed. > > 19.3.4 will need revision no matter what we decide. > > —Bill > >> On 18. Aug 2023, at 11:35, Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >> >> MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. >> >> For example, from 19.3.4: >> >> C binding >> MPI_Comm MPI_Comm_f2c(MPI_Fint comm) >> MPI_Fint MPI_Comm_c2f(MPI_Comm comm) >> >> MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). >> >> Jeff >> >>> On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov <mailto:[email protected]>> wrote: >>> >>> I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. >>> >>> Hui >>> >>> From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >>> Sent: Thursday, August 17, 2023 9:35 AM >>> To: Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> >>> Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> >>> Subject: Re: [mpiwg-abi] MPI_Fint in the ABI >>> >>> Jeff >>> >>> As per the Fortran standard, the sizes of integer and real need to be >>> the same. In practice this means that integers have 4 bytes. If >>> someone chooses to change this – either changing the size of real as >>> well or not – then they are breaking the Fortran standard, and >>> probably know what they are doing, and are aware of the various >>> incompatibilities and problems this will introduce. I would thus >>> suggest keeping things simple for the common case. I would not expect >>> there to be some code that interoperates with Fortran, and which is >>> unaware of the Fortran integer size and still expects to get things >>> right. People will either assume that integer = int, or will know the >>> Fortran ABI details. >>> >>> In the MPI ABI we assume that the caller knows sizeof(int) and >>> sizeof(void*), and I would also assume that they know sizeof(integer). >>> I would keep `MPI_Fint` a fixed type. >>> >>> To cover all bases I also suggest that we provide a global constant >>> struct with as much ABI information as we can think of, such as >>> >>> const struct MPIABI_info_t { >>> int32_t MPIABI_version_major, MPIABI_version_minor; >>> int32_t sizeof_bool; >>> int32_t sizeof_char; >>> int32_t sizeof_short; >>> int32_t sizeof_int; >>> int32_t sizeof_long; >>> int32_t sizeof_long_long; >>> int32_t sizeof_float; >>> int32_t sizeof_double; >>> int32_t sizeof_long_double; >>> int32_t sizeof_void_p; >>> int32_t sizeof_logical; >>> int32_t sizeof_integer; >>> int32_t sizeof_real; >>> int32_t sizeof_char; >>> } MPIABI_info; >>> >>> This information would not be necessary to use the ABI, but it will be >>> convenient to check assumptions. Unsupported types report a size of >>> -1. >>> >>> This struct can be extended in the future. >>> >>> -erik >>> >>> On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >>> > >>> > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. >>> > >>> > I have considered three options and would like your opinions on them: >>> > >>> > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. >>> > >>> > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. >>> > >>> > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. >>> > >>> > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. >>> > >>> > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. >>> > >>> > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. >>> > >>> > >>> > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. >>> > >>> > Thanks, >>> > >>> > Jeff >>> > >>> > -- >>> > Jeff Hammond >>> > jeff.science(a)gmail.com <mailto:[email protected]> >>> > http://jeffhammond.github.io/ >>> > -- >>> > mpiwg-abi mailing list >>> > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >>> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi >>> >>> >>> >>> -- >>> Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> -- >>> mpiwg-abi mailing list >>> mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi >> >> -- >> mpiwg-abi mailing list >> mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > -- > Bill Williams > Wiss. Mitarbeiter > ZIH-IAK, TU-Dresden > Falkenbrunnen, Room 009 > Chemnitzer Straße 50 > 01187 Dresden > Phone: +49 351 463-39976 > e-mail: william.williams(a)tu-dresden.de <mailto:[email protected]> > He/him/his >

1 0

Re: [MPIWG Fortran] [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

I just realized that option 3 doesn’t work for MPI_Status f2c/c2f, so it must be rejected. We have to choose 1 or 2. We are building an ABI to allow people to write libraries that just work with all of the implementations. This includes enabling programmers to write C libraries that interoperate with arbitrary MPI Fortran code. This code needs a way to know what MPI_Fint is without interacting with the Fortran environment. That is why we need to either prescribe the value of MPI_Fint or make it queryable from C code using MPI features. As far as ABI information, the proposal includes the following: int MPI_Abi_supported(int *flag) Int MPI_Abi_version(int *major, int *minor) int MPI_Abi_sizes(int *aint_size, int *offset_size, int *count_size, int *fint_size) int MPI_Abi_details(int *buflen, char *details) My intent with MPI_Abi_details was to allow implementations to disclose their non-standard ABI info there when flag=false. I’m happy to add an MPI_Info there if people prefer that method of including data. The struct design you propose isn’t really the MPI Way (TM). I’m not personally opposed but we don’t have a nice way to expose that in Fortran. I do not understand the need for MPIABI_info_t. We have MPI_TYPE_SIZE to query what the size of the MPI types arrow, which is what one needs to know when interacting with the ABI. Can you describe the use case where non-C code needs to know the size of a C long double, for example? If Julia is going to pass long double data into MPI, what matters if MPI_LONG_DOUBLE. Jeff > On 17. Aug 2023, at 17.35, Erik Schnetter <schnetter(a)gmail.com> wrote: > > Jeff > > As per the Fortran standard, the sizes of integer and real need to be > the same. In practice this means that integers have 4 bytes. If > someone chooses to change this – either changing the size of real as > well or not – then they are breaking the Fortran standard, and > probably know what they are doing, and are aware of the various > incompatibilities and problems this will introduce. I would thus > suggest keeping things simple for the common case. I would not expect > there to be some code that interoperates with Fortran, and which is > unaware of the Fortran integer size and still expects to get things > right. People will either assume that integer = int, or will know the > Fortran ABI details. > > In the MPI ABI we assume that the caller knows sizeof(int) and > sizeof(void*), and I would also assume that they know sizeof(integer). > I would keep `MPI_Fint` a fixed type. > > To cover all bases I also suggest that we provide a global constant > struct with as much ABI information as we can think of, such as > > const struct MPIABI_info_t { > int32_t MPIABI_version_major, MPIABI_version_minor; > int32_t sizeof_bool; > int32_t sizeof_char; > int32_t sizeof_short; > int32_t sizeof_int; > int32_t sizeof_long; > int32_t sizeof_long_long; > int32_t sizeof_float; > int32_t sizeof_double; > int32_t sizeof_long_double; > int32_t sizeof_void_p; > int32_t sizeof_logical; > int32_t sizeof_integer; > int32_t sizeof_real; > int32_t sizeof_char; > } MPIABI_info; > > This information would not be necessary to use the ABI, but it will be > convenient to check assumptions. Unsupported types report a size of > -1. > > This struct can be extended in the future. > > -erik > > On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. >> >> I have considered three options and would like your opinions on them: >> >> 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. >> >> This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. >> >> 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. >> >> 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. >> >> This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. >> >> Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. >> >> >> None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> -- >> mpiwg-abi mailing list >> mpiwg-abi(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > > > -- > Erik Schnetter <schnetter(a)gmail.com> > http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Re: [MPIWG Fortran] [mpiwg-abi] MPI_Fint in the ABI
by Jeff Hammond 18 Aug '23

18 Aug '23

MPI_Fint is part of the C ABI. It is strictly used in MPI C code to allow conversion of Fortran handles to C handles and vice versa. It must be part of the C ABI for the f2c/c2f functions to be part of the C ABI. For example, from 19.3.4: C binding MPI_Comm MPI_Comm_f2c(MPI_Fint comm) MPI_Fint MPI_Comm_c2f(MPI_Comm comm) MPI_Fint is not part of the Fortran API or ABI, because Fortran handles are defined to be INTEGER (or an INTEGER inside of a type(MPI_Handle) object). Jeff > On 17. Aug 2023, at 17.52, Zhou, Hui <zhouh(a)anl.gov> wrote: > > I haven't gone through all the use cases, but my current opinion is, it is really a Fortran binding issue and should be left out of C ABI. > > Hui > > From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> on behalf of Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> > Sent: Thursday, August 17, 2023 9:35 AM > To: Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> > Cc: mpiwg-abi <mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]>>; MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> > Subject: Re: [mpiwg-abi] MPI_Fint in the ABI > > Jeff > > As per the Fortran standard, the sizes of integer and real need to be > the same. In practice this means that integers have 4 bytes. If > someone chooses to change this – either changing the size of real as > well or not – then they are breaking the Fortran standard, and > probably know what they are doing, and are aware of the various > incompatibilities and problems this will introduce. I would thus > suggest keeping things simple for the common case. I would not expect > there to be some code that interoperates with Fortran, and which is > unaware of the Fortran integer size and still expects to get things > right. People will either assume that integer = int, or will know the > Fortran ABI details. > > In the MPI ABI we assume that the caller knows sizeof(int) and > sizeof(void*), and I would also assume that they know sizeof(integer). > I would keep `MPI_Fint` a fixed type. > > To cover all bases I also suggest that we provide a global constant > struct with as much ABI information as we can think of, such as > > const struct MPIABI_info_t { > int32_t MPIABI_version_major, MPIABI_version_minor; > int32_t sizeof_bool; > int32_t sizeof_char; > int32_t sizeof_short; > int32_t sizeof_int; > int32_t sizeof_long; > int32_t sizeof_long_long; > int32_t sizeof_float; > int32_t sizeof_double; > int32_t sizeof_long_double; > int32_t sizeof_void_p; > int32_t sizeof_logical; > int32_t sizeof_integer; > int32_t sizeof_real; > int32_t sizeof_char; > } MPIABI_info; > > This information would not be necessary to use the ABI, but it will be > convenient to check assumptions. Unsupported types report a size of > -1. > > This struct can be extended in the future. > > -erik > > On Wed, Aug 16, 2023 at 4:09 AM Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: > > > > As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. > > > > I have considered three options and would like your opinions on them: > > > > 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. > > > > This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. > > > > 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. > > > > 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. > > > > This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. > > > > Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. > > > > > > None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. > > > > Thanks, > > > > Jeff > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com <mailto:[email protected]> > > http://jeffhammond.github.io/ > > -- > > mpiwg-abi mailing list > > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> > > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > > > > -- > Erik Schnetter <schnetter(a)gmail.com <mailto:[email protected]>> > http://www.perimeterinstitute.ca/personal/eschnetter/ > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

MPI_Fint in the ABI
by Jeff Hammond 16 Aug '23

16 Aug '23

As we all know, Fortran users are permitted to change the size of INTEGER with compiler flags. This creates a problem for the MPI C ABI. I have considered three options and would like your opinions on them: 1. MPI_Fint is defined to be a C int in the standard ABI. This means MPI implementations that elect to provide an ILP64 MPI Fortran ABI on an I32LP64 system, for example, must not call this an implementation of the standard ABI. This would make a lot of things easier, but it might cause problems in the rare cases where users are using ILP64 in Fortran and using C code that actually uses MPI_Fint. 2. MPI_Fint ceases to be a compile-time fixed type in the standard ABI. The C code that uses MPI_Fint must make an MPI library call to figure out the size and do all of the necessary things to call the correct size. 3. MPI_Fint is not a fixed size but the standard ABI specifies that Fortran handle values must always fit into the range of a C int and we rely on the pass-by-value behavior of all the f2c/c2f APIs to behave properly when they are truncated. This is my preference but it breaks Example 19.11 in a serious way, because that user code makes use of a MPI_Fint pointer. However, this code isn't standard-compliant and relies on universal but non-standard argument passing conventions in Fortran. Writing a standard-compliant interface from Fortran to C - by doing the cast to INTEGER(kind=c_int) in Fortran - would resolve this. Example 19.11 is awful (https://github.com/mpi-forum/mpi-issues/issues/739) but it is nonetheless important to instruct users that if Option 3 is implemented, they need to do the casting to INTEGER(kind=c_int) and know that this is safe with the standard ABI. None of these options is perfect. I'm not sure how much code is even impacted by MPI_Fint so it's hard to know which option breaks the most stuff, although Option 2 seems the least desirable in any case. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions
by Malcolm Cohen 25 Nov '22

25 Nov '22

Hi Jeff, Yes, TARGET is part of the characteristics. See 15.3, in particular, 15.3.2.2 which has " or a target (8.5.18, 8.6.15)". Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. -----Original Message----- From: Jeff Hammond <jeff.science(a)gmail.com> Sent: Monday, November 21, 2022 4:23 PM To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> Cc: Malcolm Cohen <malcolm(a)nag-j.co.jp>; Brandon Cook <bgcook(a)lbl.gov> Subject: Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions Thanks, Malcolm. I suspected this was the case. > > No, my_function is not compatible with MPI_User_function_f18 as it has different characteristics. > Is any of the following not load-bearing? For example, is “target” an essential part of signature compatibility? It’s fine if it is, I just don’t want to over-specify in MPI. subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine The following is compatible and does the same thing, albeit with more work. Is this acceptable? Because users write this code, they usually know what the arguments are going to be and don’t need to do any type inquiry, but since there can be only one callback signature, it needs to be completely general. subroutine X_function(invec, inoutvec, len, datatype) use, intrinsic :: iso_c_binding, only : c_ptr, c_loc, c_f_pointer use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype ! type(c_ptr) :: cpi, cpo integer, dimension(:), pointer :: fpi, fpo cpi = c_loc(invec) cpo = c_loc(inoutvec) call c_f_pointer(cpi,fpi,[size(invec)]) call c_f_pointer(cpo,fpo,[size(inoutvec)]) fpo = fpo + fpi end subroutine > It is also unlikely to work in practice despite the Intel acceptance at compile time, as an assumed-rank descriptor is unlikely to be exactly the same as a Fortran-90 assumed-shapee array descriptor. Indeed, I forgot this, and I know it’s true for GCC. > > Also REAL is not compatible with TYPE(*) so it fails on that front too. > > On a more philosophical note, I don’t quite see what purpose LEN is meant to achieve. Surely you just pass it the array slice you want to be reduced, no need to tell it the size separately, no? > Yes, you are not the first to note this. However, all MPI functions have a buffer, size and type argument. For better or worse, MPI insists on symmetry across languages, and C is clearly the limiter here. Furthermore, the when MPI_Reduce invokes MPI_User_function, it provides a size and a type, and we need a way to handle that, if the user decides to use them. I have considered proposing a new sentinel for MPI that causes the implementation to ignore size and type and instead infer them from the Fortran descriptor but I don’t know if the MPI Forum has the appetite for this right now. I have a project [1] to make a more natural MPI Fortran interface that does not use the unnecessary size and type arguments that are redundant with array descriptors but I’m not sure if it belongs in MPI when an open-source library solves the problem. We’ve had enough trouble with Fortran support in MPI implementations already. Jeff 1. https://github.com/jeffhammond/galaxy-brain - sorry, there is no documentation. > Cheers, > -- > ..............Malcolm Cohen, NAG Oxford/Tokyo. > > From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpiwg-fortran > Sent: Monday, November 21, 2022 12:09 AM > To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions > > Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in https://github.com/mpi-forum/mpi-issues/issues/576. > > I looked at this and it appears we can do something better (https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: > > abstract interface > > subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > type(*), dimension(..), target, intent(in) :: invec > type(*), dimension(..), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > end subroutine > > end interface > > which allows the user to create their own reduce functions, e.g.: > > subroutine MY_function(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > real, dimension(:), target, intent(in) :: invec > real, dimension(:), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > inoutvec = inoutvec + invec > end subroutine > > Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. > > Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. > > Thanks! > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

1 0

Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions
by Jeff Hammond 21 Nov '22

21 Nov '22

Thanks, Malcolm. I suspected this was the case. > > No, my_function is not compatible with MPI_User_function_f18 as it has different characteristics. > Is any of the following not load-bearing? For example, is “target” an essential part of signature compatibility? It’s fine if it is, I just don’t want to over-specify in MPI. subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine The following is compatible and does the same thing, albeit with more work. Is this acceptable? Because users write this code, they usually know what the arguments are going to be and don’t need to do any type inquiry, but since there can be only one callback signature, it needs to be completely general. subroutine X_function(invec, inoutvec, len, datatype) use, intrinsic :: iso_c_binding, only : c_ptr, c_loc, c_f_pointer use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype ! type(c_ptr) :: cpi, cpo integer, dimension(:), pointer :: fpi, fpo cpi = c_loc(invec) cpo = c_loc(inoutvec) call c_f_pointer(cpi,fpi,[size(invec)]) call c_f_pointer(cpo,fpo,[size(inoutvec)]) fpo = fpo + fpi end subroutine > It is also unlikely to work in practice despite the Intel acceptance at compile time, as an assumed-rank descriptor is unlikely to be exactly the same as a Fortran-90 assumed-shapee array descriptor. Indeed, I forgot this, and I know it’s true for GCC. > > Also REAL is not compatible with TYPE(*) so it fails on that front too. > > On a more philosophical note, I don’t quite see what purpose LEN is meant to achieve. Surely you just pass it the array slice you want to be reduced, no need to tell it the size separately, no? > Yes, you are not the first to note this. However, all MPI functions have a buffer, size and type argument. For better or worse, MPI insists on symmetry across languages, and C is clearly the limiter here. Furthermore, the when MPI_Reduce invokes MPI_User_function, it provides a size and a type, and we need a way to handle that, if the user decides to use them. I have considered proposing a new sentinel for MPI that causes the implementation to ignore size and type and instead infer them from the Fortran descriptor but I don’t know if the MPI Forum has the appetite for this right now. I have a project [1] to make a more natural MPI Fortran interface that does not use the unnecessary size and type arguments that are redundant with array descriptors but I’m not sure if it belongs in MPI when an open-source library solves the problem. We’ve had enough trouble with Fortran support in MPI implementations already. Jeff 1. https://github.com/jeffhammond/galaxy-brain - sorry, there is no documentation. > Cheers, > -- > ..............Malcolm Cohen, NAG Oxford/Tokyo. > > From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpiwg-fortran > Sent: Monday, November 21, 2022 12:09 AM > To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions > > Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in https://github.com/mpi-forum/mpi-issues/issues/576. > > I looked at this and it appears we can do something better (https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: > > abstract interface > > subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > type(*), dimension(..), target, intent(in) :: invec > type(*), dimension(..), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > end subroutine > > end interface > > which allows the user to create their own reduce functions, e.g.: > > subroutine MY_function(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > real, dimension(:), target, intent(in) :: invec > real, dimension(:), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > inoutvec = inoutvec + invec > end subroutine > > Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. > > Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. > > Thanks! > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

1 0