From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri Mar 29 15:50:02 2024 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id B74D2356DF2; Fri, 29 Mar 2024 15:50:02 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2100.outbound.protection.outlook.com [104.47.65.100]) by www.open-std.org (Postfix) with ESMTP id 1B460356DAE for ; Fri, 29 Mar 2024 15:50:01 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WJfn6UeY5ow+XROCn1iEQ82IHxJIeHSrO3jIg9VQBuAW0fSu0+LFuBbh3qIkx+Cix7Dn2pWrr0HrpQrYC0+wb1xMQi9ZF9sSH0tIzdAoRLMX9J4+e1KjQJT7YFOgNOgSxsb7UPpWkgmx+2SHcpRMQFQ/47fwGmm04bGWlrBcibOrbnW00nuyH/z62uYJsEidObwBaOsMdsZoJNlwDI1OkJkd1IEaK+nfWNCVsPf4njkesJPLONDMZ0+1qFPdD7/pJ8MImGEOiNcytnLmoCfMxIk/HNpyjFp2OHJazhQfMe7seN5btY2qcXp7Jx5L9gTxaje8YxS9mmqvKu2OLXcAmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Fx3uVE79nf765+cDpYNM979cJdKlesFErr6YZTX37MA=; b=R9aYdOpLfi2aov/YkWElgXBOZ+cDcgzUpdEwfB6t1p5daKWKklJdpriWFTe7SMgRyGiFC1XZLx2H3gHUmuk0hWuZg3rhRD32XFhyyO6VCDxp5kSAwIso04d5thkpcg/mwsXK/ZNd+mGsvvPNwOyxC+yVtNvx2UcYCk2gu7K05c971fO1u2o6dO//QjctPwuXXRPcPg20EbJjrRd1TnNu+HZjUr+2yN3+EPia/XJYiISNQhZXNQURChW5grBkvrioi9qs8+lxKt7zVJvZPnV6uIu8xra09qyz1ONgScngGcP0A5DH/51Q9013Ad0c3jmxWKm3gO+spvzVtJ+u9zDkzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nasa.gov; dmarc=pass action=none header.from=nasa.gov; dkim=pass header.d=nasa.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nasa.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fx3uVE79nf765+cDpYNM979cJdKlesFErr6YZTX37MA=; b=ZD8CeoEN8uQcZfFtp0nkRDIANLq3gixdGklAJo7MCmy2srSFtBVd52sIgJ2Ujh8I1zpcXU0ZyrtNfz/QfudkbqBW3Ka3FBYyaRZka5kyZBP+Vp61/SoHwnCcmye84ZjpXQoI7InBFyhC+NXaelbtylmrzPZ9RiAkv5dP+nyauHc= Received: from PH0PR09MB7385.namprd09.prod.outlook.com (2603:10b6:510:62::18) by BLAPR09MB6514.namprd09.prod.outlook.com (2603:10b6:208:2a3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.41; Fri, 29 Mar 2024 14:49:58 +0000 Received: from PH0PR09MB7385.namprd09.prod.outlook.com ([fe80::74f:c0cf:2048:5394]) by PH0PR09MB7385.namprd09.prod.outlook.com ([fe80::74f:c0cf:2048:5394%7]) with mapi id 15.20.7409.023; Fri, 29 Mar 2024 14:49:58 +0000 From: "Clune, Thomas L. (GSFC-6101)" To: General J3 interest list , WG5 CC: Jeff Hammond Subject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - please help with MPI Fortran Thread-Topic: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - please help with MPI Fortran Thread-Index: AQHagcIPXHcNYSj5h0CgOXx8WJHTJ7FOzDdr Date: Fri, 29 Mar 2024 14:49:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR09MB7385:EE_|BLAPR09MB6514:EE_ x-agency-banner-exclusion: 1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3lB18IOiuTZXse2eWs8LSap4XM4zx0mIwatAJtFCUt4VBX3zWf5eSphLGH9Wsd/+PAFyeT+xIo7c62JT43xowLe7NO/GakMiAunpDjbJSKZDkVPijJ1cjUu/1mQt+JSqyVEs2mMLn7lLJdBdDKGt/XBJJ7SUxboI1cx6z2joHhxOOTfNbaRaSO9OMFTppCXXWU4Xum2wb16QB8gnkD0qizjvdzTOS9s2J3dNLxXkkYNMnAKvtj7gfZoOMUf0dJ/RADCwqeIM9ti2Xs8Z/sgwB4idRmdhPRIESn7SwPcyU7+b9ivCF/unZmC61SXtimU8vwHyvKjM/W67b8lteXyKXabgSTaUE4NQMWxSnCfgjpT49KI2VuTWAoZUHE94voDvV4Ka35VZdjuBRTxvkIYb3qBAWife2HCl+dNj+0iI0U5+zFZcK8jBxCC7fN31b310b86o+/KX3X33QFcBUKEj559xIu9yw7k3IaoPMSRQGPoWGssLhrzsZKeKhLt0LJcE2z+iAHB9Izg2z4teGCiNxbmURgb720Yar8L/j90mD0JSh4POOcUKVYmYhtTVrpgFgwNyHfeEUSq0baH8v5AuABwhcIefOYM8gJIItxMUqcQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR09MB7385.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?FcprykK3018ZxLURDch0bpZyOpm9uhqP2FshIPbXUeEooeEAokBZ7OfY?= =?Windows-1252?Q?H47SZQ0ZCeAUAtgcXiVOY5q4TMNms8qfzy3HuZhg2wIhEIMZRJ9OIR1v?= =?Windows-1252?Q?HGuJwh02QJBHPbQLmDV3n2aRZ1fePPABCt847lg/NMi9RJW0JVXo7HWf?= =?Windows-1252?Q?ulyUS/K/WrSgPwSDuVRWhA662TE9CRPkYoJnSY4Xip9ADkONyEuE3eNr?= =?Windows-1252?Q?aFODszxj1xTaoDHcjL5PhEBHdLbkM17td/b1Z6R8nBR2nCZAzctoSjgV?= =?Windows-1252?Q?lx2yWvq+fM0Lu2c2rM7E+pwQ8lgisjH7ArHf74YT6YcOrYIwK5zSkNpx?= =?Windows-1252?Q?p9QIYUcgc1ZtWb1zwNGLlba7KPY8oIkxeZ8VCV6ZZiOv6jyvHe0esKDf?= =?Windows-1252?Q?XrfPqkZs91szkWuQiHHrGX9FaYAN8bgtH/Rv4xLCt8E0SmXQ+S/o4Fs9?= =?Windows-1252?Q?N/BVX0UP+6rw/hoLegAWV7lu+/HDfmOxSb8vKCQlp+WtAf4VneQynVxp?= =?Windows-1252?Q?FU9rH9ThYMbavq6irIR2nLYlf50RATf7IpfnSTi3FcgBalH2C2zEEZpf?= =?Windows-1252?Q?/aI/w4fHi2KA12uClFiMIejhHpqj2XSB68c0YXlX3ZerQqRggXAogV0V?= =?Windows-1252?Q?rcwijMA/SLtsBla8bJCVnNsXHMpYCy9HkrM2xuebvyED0wPvEYaTHfGo?= =?Windows-1252?Q?6fZsEP3NwjUkGHoOy7ZY5WPW6V1psOCPGeuVW07QM2NI3581t8PdJhgQ?= =?Windows-1252?Q?0fwegoALx+U6AJD3JqPFNhx26LZuPlqR27x4rPktSMoKUOfWIdy6T9Bz?= =?Windows-1252?Q?yyc03GtzCc2cCfew46OkyXbPfQswgg/No8tYd0EnxmupEU0P4pWem5ad?= =?Windows-1252?Q?4z6eqyBIVw3iB3TFDPGkgntonEQBug9Pi4GeIYZPO+m4D7WNLNPW2Trw?= =?Windows-1252?Q?q1seCjgL7O0ricC6tW45ky0BQaSQqMKO63NjifY3owO7PrHGrYfPJkWx?= =?Windows-1252?Q?GmEauMGAWLXm0XDXV0ld+ZyGS/yoPfIWrop6Sjn39E3o6dKlXq/IrnzM?= =?Windows-1252?Q?8tYf0x4iMYnYdCWxFNrTxfNuLmoHhdOVgghOQr7TEyASJENSKwx9JUTu?= =?Windows-1252?Q?a9je7ZSehoNaYNpnfdmBavrE0VfaR/8ysZe4VSlwxs5S7eclTJRCEZFA?= =?Windows-1252?Q?d5BFdBQ7KnHTJtgB7UorwhArzbm6OJ4WI4nDjXbM6/GxH4WX+Av0+eTS?= =?Windows-1252?Q?wBOMsQgq/pgh1+3ghHSyyVh7s6T/gNrvNnuJ4LVs+y1YAjn6ZX1/Bg8X?= =?Windows-1252?Q?GHwzR6+GQRRq2v+6rJ4adKOisJgy51QKmlmABouaQedr/ikBjxJLWqpf?= =?Windows-1252?Q?CvfBhgBBtGCjp/UD3qMj/2O9FICUFP6GYVlIRuEd/QxqI2Pbfxq9tTim?= =?Windows-1252?Q?7ef2XKd/qvMt245GqjeuhEN0Fbtb1QjNduMH8xnmwOVRwqf6iiI0c4ry?= =?Windows-1252?Q?PfUtiuHz9EMOVE52NAhHLyyt/xjU61Xp7DVIn5L9sR8S8dFAQkeR+6HX?= =?Windows-1252?Q?ZMXjhpaqRTef2GdmQI9mF2IdDJVpSmJOiJcj06r9KBZrvtlAV9x/nZ1i?= =?Windows-1252?Q?GVslKlbw4r3kmdT01CouoSAXyHEjr30luQf/oWVzMzjKhirSjGPLzijF?= =?Windows-1252?Q?D1VjwndAQ0ijCBObArYmAgvLJlg7M4QqwkVi6cxzbm6vV97RiVlr5w?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR09MB73857DFD17E3412361261A6EA63A2PH0PR09MB7385namp_" MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 5N22jzGP4vx+ZPcd5SxV6yH9SxNbv+Pyk+gqtxQbadeRTRwCfYeOVIYMA4dBjXfEVNMuF/m/0LLv4chC7eHHzTMg8q1lZKBIo5NjhMwWYCE6nrHhf6DBBZidphCDjsgcCM6VES+A4mxQZUQR5zi0UfXPLFcDa3bVbYaqsZotoxn31kkHm6zQcV/q0eRcyLYAxpzdWKMJ7RYLR+ZSeM3AVa8VofZ4TJJaBzsqOns1Mip9wWpFCbNHkhQcU50smOYlBEVV4SgeP8v3D22T2lskodOYa0Z8wquQij0J8k9Lo6c+tC9Ztqb4pfAv7g/hmEv42GRuyPsXccJHfO/kcIOTYqFN9tsVQ/yYbA8joumXOHq02oEX7KtfAlyvwe7NiPWmqSUv2ksgROAfjO7VnU0INiLdU5BTCrSG8d5+L/GdD6WQI9al9PpD4X8Sptvv4aX1psp2BgC1dIV+7TGu7ZH774CYv/LCXzwbG5vBa4IcoqrQMzxKgYKjEeJO0ZOaPPykEU1UsDMolvOj/FzjNyMl6WVocEhOOG3jg4Tbv8d1ueOE/8oVhMm3wy9m1Q0juQyHPg08e+2EvR/wW4Y/FiqWRu4fljChNOMHKW9R143xCo8= X-OriginatorOrg: nasa.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR09MB7385.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c699df9-e676-4d94-e3ea-08dc4fff8114 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 14:49:58.0404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7005d458-45be-48ae-8140-d43da96dd17b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6514 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_PH0PR09MB73857DFD17E3412361261A6EA63A2PH0PR09MB7385namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jeff, Why can=92t the Fortran interface be in terms of MPI-specific kinds? Use mpi_f08, only: KIND_MPI_AINT, KIND_MPI_FLOAT, KIND_MPI_ADOUBLE Integer(kind=3DKIND_MPI_AINT) :: =85 Real(kind=3DKIND_MPI_AFLOAT) :: =85 Real(kind=3DKIND_MPI_ADOUBLE) :: =85 Users for which these align with compiler defaults will not need to change = their code, but the recommendation will be for them to use the more explici= t kinds. I=92m sure I=92m missing something. * Tom From: J3 on behalf of Jeff Hammond via = J3 Date: Friday, March 29, 2024 at 10:33 AM To: WG5 Cc: Jeff Hammond Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - please = help with MPI Fortran CAUTION: This email originated from outside of NASA. Please take care when= clicking links or opening attachments. Use the "Report Message" button to= report suspicious messages to the NASA SOC. Per 19.5.3.2 Storage sequence, the following default type sizes are possibl= e, assuming that type sizes must not go outside the ranges defined in ISO_F= ORTRAN_ENV: a. 16-bit INTEGER, LOGICAL and REAL; 32-bit DOUBLE PRECISION and COMPL= EX i.e. NUMERIC_STORAGE_SIZE=3D16 b. 32-bit INTEGER, LOGICAL and REAL; 64-bit DOUBLE PRECISION and COMPL= EX i.e. NUMERIC_STORAGE_SIZE=3D32 c. 64-bit INTEGER, LOGICAL and REAL; 128-bit DOUBLE PRECISION and COMP= LEX i.e. NUMERIC_STORAGE_SIZE=3D64 d. 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 comp= uted with FP64. There are of course many compilers that support (d), via s= uch options as -i8, which some committee members have told me are abominabl= e. The MPI Forum is considering standardizing primitive type sizes, as a so-ca= lled 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 comp= ile on a given platform). We do this in the C API by binding MPI=92s integ= er 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 defini= tions 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 F= ortran remains a first-class language in MPI. However, some members object= to me choosing definitions corresponding to (b) because =93Fortran doesn= =92t say INTEGER is equivalent to C int=94 and therefore, since we can=92t = 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 F= ortran doesn=92t specific (b), but in practice, (b) is the only standard-co= mpliant choice in use today, and it is used the overwhelming majority of th= e 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 M= PI Fortran as a library on top of C. Bill Long has said he thinks is a goo= d thing, and which I have partially implemented in order to give MPI Fortran broader compiler support and more c= omplete feature support than they can get from MPICH and Open MPI today. T= he 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 pla= tforms, e.g. x86 still doesn=92t have native FP16 for REAL in (a) and no pl= atform 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. I= ntel 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=92= m asking for WG5 members to provide me with some support that choosing (b) = is better than nothing at all, for MPI=92s Fortran users. I=92ll note that we won=92t take anything away from MPI Fortran with implem= entation-defined behavior today, which are configured with whatever type si= zes 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 u= sage 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 us= able behind a compiler-specific but MPI-implementation-agnostic implementat= ion of MPI Fortran support. My fear is that if I cannot convince the MPI Forum to standardize the MPI A= BI to include Fortran support in the C library ABI, that Fortran will becom= e even worse off than Python, Julia and Rust, which do not have the same ba= ckwards-compatibility issues that MPI Fortran does, because their MPI suppo= rt is not standardized and those languages haven=92t been used for decades = like Fortran has. The alternative designs to my proposal add significant o= verhead to MPI Fortran versus C or break Fortran use cases in minor ways (a= pparently, breaking =93a few=94 Fortran codes is acceptable to the MPI Foru= m 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 to= pic and I=92ve spent about 3000 hours getting to this point, so at some lev= el you all will have to trust than I am distilling this topic down appropri= ately. Thanks, Jeff --_000_PH0PR09MB73857DFD17E3412361261A6EA63A2PH0PR09MB7385namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Jeff,

 

Why can=92t the Fortran interface be in terms of MPI= -specific kinds?

 

Use mpi_f08, only: KIND_MPI_AINT, KIND_MPI_FLOAT, KI= ND_MPI_ADOUBLE

Integer(kind=3DKIND_MPI_AINT) :: =85

Real(kind=3DKIND_MPI_AFLOAT) :: =85

Real(kind=3DKIND_MPI_ADOUBLE) :: =85

 

Users for which these align with compiler defaults w= ill not need to change their code, but the recommendation will be for them = to use the more explicit kinds.

 

I=92m sure I=92m missing something.

 

  • Tom

 

 

 

From: J3 <j3-bounces@mailman.j3-fortran.org= > on behalf of Jeff Hammond via J3 <j3@mailman.j3-fortran.org>
Date: Friday, March 29, 2024 at 10:33 AM
To: WG5 <sc22wg5@open-std.org>
Cc: Jeff Hammond <jehammond@nvidia.com>
Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - = please help with MPI Fortran

CAUTION: This email originated f= rom outside of NASA.  Please take care when clicking links or opening = attachments.  Use the "Report Message" button to report susp= icious messages to the NASA SOC.



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:

a.      16-bit INTEGER, LO= GICAL and REAL; 32-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SI= ZE=3D16

b.      32-bit INTEGER, LO= GICAL and REAL; 64-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SI= ZE=3D32

c.      64-bit INTEGER, LO= GICAL and REAL; 128-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_S= IZE=3D64

d.      <things that vi= olate 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 SG= EMM computed with FP64.  There are of course many compilers that support (d), via such options as -i8, which som= e 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=92s 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 m= embers object to me choosing definitions corresponding to (b) because =93Fortran doesn=92t say INTEGER is equivalent to C int=94 = and therefore, since we can=92t pick one option, we must pick none and make= Fortran-related aspects of the C API implementation-defined in the ABI.&nb= sp; They are of course correct that Fortran doesn=92t specific (b), but in practice, (b) is the only standard-compliant choice i= n 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 mea= ns 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 in order to give MPI Fortran broader compiler support and m= ore complete feature support than they can get from MPICH and Open MPI toda= y.  The other issue is that it makes MPI Fortran less usable within th= e 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=92t have native FP16 for REAL in (a) a= nd 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-comp= liant is better than no choice at all.

 

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

 

I=92ll note that we won=92t take anything away from MPI Fortran wit= h 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 dem= and 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 MP= I C API ABI usable behind a compiler-specific but MPI-implementation-agnost= ic implementation of MPI Fortran support.

 

My fear is that if I cannot convince the MPI Forum to standardize t= he MPI ABI to include Fortran support in the C library ABI, that Fortran wi= ll 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 th= ose languages haven=92t been used for decades like Fortran has.  The a= lternative designs to my proposal add significant overhead to MPI Fortran versus C or break Fortran use cases in minor ways = (apparently, breaking =93a few=94 Fortran codes is acceptable to the MPI Fo= rum if it means they get to spend less time thinking about Fortran).=

 

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

 

Thanks,

 

Jeff

--_000_PH0PR09MB73857DFD17E3412361261A6EA63A2PH0PR09MB7385namp_--