[J3] [SC22WG5.6574] Fortran type sizes - please help with MPI Fortran

[Jeff Hammond]

Per 19.5.3.2 Storage sequence, the following default type sizes are possible, assuming that type sizes must not go outside the ranges defined in ISO_FORTRAN_ENV:

  1.  16-bit INTEGER, LOGICAL and REAL; 32-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=16
  2.  32-bit INTEGER, LOGICAL and REAL; 64-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=32
  3.  64-bit INTEGER, LOGICAL and REAL; 128-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=64
  4.  <things that violate the cited text of the standard>

I am not aware of any platform used this century that supports (a) and only know that Cray implemented (c) at one point long ago, such that SGEMM computed with FP64.  There are of course many compilers that support (d), via such options as -i8, which some committee members have told me are abominable.

The MPI Forum is considering standardizing primitive type sizes, as a so-called ABI standard (I understand this term may bother some, but its meaning is different from a platform ABI and defined in terms of how MPI types compile on a given platform).  We do this in the C API by binding MPI’s integer types to the platform C behavior, i.e MPI_Aint (an integer that holds an address) is defined to be intptr_t, and so forth.  Specifying these definitions means that implementations of the MPI C API are interoperable at the shared-library level, which is a big deal for software distribution (https://dl.acm.org/doi/fullHtml/10.1145/3615318.3615319 has details).

I am attempting to support some aspects of Fortran in the C ABI to ensure Fortran remains a first-class language in MPI.  However, some members object to me choosing definitions corresponding to (b) because “Fortran doesn’t say INTEGER is equivalent to C int” and therefore, since we can’t pick one option, we must pick none and make Fortran-related aspects of the C API implementation-defined in the ABI.  They are of course correct that Fortran doesn’t specific (b), but in practice, (b) is the only standard-compliant choice in use today, and it is used the overwhelming majority of the time.

The MPI Forum will ultimately decide between (b) and nothing.  In this case, nothing means that Fortran datatypes and C-interoperability routines will not be part of the C ABI, which will make it more difficult to implement MPI Fortran as a library on top of C.  Bill Long has said he thinks is a good thing, and which I have partially implemented<https://github.com/jeffhammond/vapaa> in order to give MPI Fortran broader compiler support and more complete feature support than they can get from MPICH and Open MPI today.  The other issue is that it makes MPI Fortran less usable within the MPI ABI ecosystem, which is expected to be adopted in several settings.

My case for MPI standardizing its API based on (b) is based on:
(1) all compilers default to this choice and is the only one I know that is available from every compiler
(2) both (a) and (c) cannot be implemented natively in hardware on many platforms, e.g. x86 still doesn’t have native FP16 for REAL in (a) and no platform I know has native hardware FP128 for DOUBLE PRECISION in (c);
(3) all software libraries in binary form support either (b) or (d), e.g. Intel supplies MKL for (b) and ILP64, which is (d);
(4) a choice that covers ~90% of usage and is Fortran-standard-compliant is better than no choice at all.

Obviously, we will not change the Fortran standard to specify (b), but I’m asking for WG5 members to provide me with some support that choosing (b) is better than nothing at all, for MPI’s Fortran users.

I’ll note that we won’t take anything away from MPI Fortran with implementation-defined behavior today, which are configured with whatever type sizes the builder wants, which is (b) by default and only ever (d) otherwise.  However, there is strong demand for the C ABI for many reasons, including redistributable libraries and containers as well as third-party language usage in Rust, Python and Julia, so we expect many users to move to the MPI ABI definitions, which allow swapping of MPI C implementations, at least.  Fortran modules are not interoperable, but we can make the MPI C API ABI usable behind a compiler-specific but MPI-implementation-agnostic implementation of MPI Fortran support.

My fear is that if I cannot convince the MPI Forum to standardize the MPI ABI to include Fortran support in the C library ABI, that Fortran will become even worse off than Python, Julia and Rust, which do not have the same backwards-compatibility issues that MPI Fortran does, because their MPI support is not standardized and those languages haven’t been used for decades like Fortran has.  The alternative designs to my proposal add significant overhead to MPI Fortran versus C or break Fortran use cases in minor ways (apparently, breaking “a few” Fortran codes is acceptable to the MPI Forum if it means they get to spend less time thinking about Fortran).

I apologize if this is not entirely clear.  This is a wildly complicated topic and I’ve spent about 3000 hours getting to this point, so at some level you all will have to trust than I am distilling this topic down appropriately.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20240329/070ba898/attachment.htm>