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

[Jeff Hammond]

The issue is, we have 30 years of MPI Fortran code that does things that are correct according to MPI and Fortran, but which are broken if we do certain things that are otherwise very nice from a software design perspective.  Breaking user code is bad for business, as everybody here knows :-)

If we could redefine MPI Fortran to use ISO_C_BINDING types, we’d have zero problems, but ISO_C_BINDING came a decade after MPI was created and Fortran 2003 compilers weren’t widely available until well after 2003.

Jeff

On 29. Mar 2024, at 16.51, Brad Richardson via J3 <j3 at mailman.j3-fortran.org> wrote:

External email: Use caution opening links or attachments

Hi Jeff,

I believe that

> The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall be at
least 37. It is recommended that the decimal precision of default real be at least 6, and that its decimal exponent
range be at least 37.

taken together with

> numeric storage unit: unit of storage that holds a default real, default integer, or default logical value
> a nonpointer scalar object that is default integer, default real, or default logical occupies a single
numeric storage unit,
> a nonpointer scalar object that is double precision real or default complex occupies two contiguous
numeric storage units,

means that option (a) would be non-conforming. Somebody feel free to correct me if I'm wrong about that.

At any rate, IMO it would be the right choice for MPI to specify option (b) for its "ABI", and have a minor disclaimer about that for Fortran users. My guess is >90% of users expect it already. Question though, why would it not make sense for the MPI Fortran interfaces to be specified in terms of the C equivalent kind parameters from ISO_C_BINDING? That way if C_INT /= kind(1) at least the compiler will yell at you about it.

Regards,
Brad

On Fri, 2024-03-29 at 14:33 +0000, Jeff Hammond via J3 wrote:
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/018da19e/attachment-0001.htm>