From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri Mar 29 16:58:24 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 D70B5356DF2; Fri, 29 Mar 2024 16:58:23 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from BLAPR09CU002.outbound.protection.outlook.com (mail-eastusazlp17011008.outbound.protection.outlook.com [40.93.11.8]) by www.open-std.org (Postfix) with ESMTP id 2A4B2356DD2 for ; Fri, 29 Mar 2024 16:58:21 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g44QtmCzCOuwGC+2HiNEIFWjtf9zxsJxbRkOzkBt5CNChchAPh6Sfo0bugiQYjR670LZSGsyD8uEFRuZBxodnduENgFofUtKetjybl4jBCbgXDK6PujjCRvjGzzoUEuuylFvHZ3iqH//6qzWbRrF17r6YsQ2xcMZfGrrDzQ8X3+svkjJ5HCFy9RsUbjoZ4QRvzTVcwcM2dXl0rUBDaFJrHdtAfFJ0Lav3eIevKgll2VlXt8ZdRTMnXFf4zMpDIpZh9vGYY/EedbV7Qb6YG67BhpXSoRgg79dGQLFE1qqUzeJSzR5LnDPPxFt+B3v4WjeqsYRkZcQDgGlR4GuIZdy1w== 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=pL6U18et1t1XXPWirYOsDYLnIoGpGBVpd6dhRMLib6Q=; b=C418UhfXZtnKDCUPuCURyTLiz4THdJfMnFzevw87AfvWCabLqQpMd6eyv87cw9S/8lKtlXxae3rowQXmbQEdM812mfwZ7Z6IEM4WGj1lbMjck4seh3yqrtL2tBrioD7jzA5IHy2KzAC4LRAsbkPwu3qJ1VvLfYsPMkBz17aiNsyVbjk6rXzcyehYNAE7+4W1yZlNSwK0XFHGJARLDWp/YGAIaGv0AcriJk449iUv89yUu/C10IDzMeT6bhSlvESVEGnTzI0AL3tgdU4u8du7VLPD8X947heNEVTuebwBpoHvVd0jBxkkRlzVWOrhvRnTe/c6GkBsbdmXbjm4P3hu7w== 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=pL6U18et1t1XXPWirYOsDYLnIoGpGBVpd6dhRMLib6Q=; b=WxYtyBJVo82z1zpxKo6IQYSGmbpegpfSuPvumQdmsnOXTjJPjYaxy6orq6u0PuKaGZxQCfXW9OK8NwOokUnAm25b6xGV3Qgp03Me6SWRBWqmPvIEUAdoFd3carmzG3dwwtz6vwCGe0fLQeHe3EAdRlJE4lDgBdfkmnYEPSWL8gk= Received: from PH0PR09MB7385.namprd09.prod.outlook.com (2603:10b6:510:62::18) by SJ0PR09MB10228.namprd09.prod.outlook.com (2603:10b6:a03:468::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.40; Fri, 29 Mar 2024 15:58:12 +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 15:58:12 +0000 From: "Clune, Thomas L. (GSFC-6101)" To: Jeff Hammond CC: General J3 interest list , WG5 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: AQHagcIPXHcNYSj5h0CgOXx8WJHTJ7FOzDdrgAAL/ACAAAbjsg== Date: Fri, 29 Mar 2024 15:58:12 +0000 Message-ID: References: <447CB7F2-4639-47FA-BB46-118C8BE6C980@nvidia.com> In-Reply-To: <447CB7F2-4639-47FA-BB46-118C8BE6C980@nvidia.com> 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_|SJ0PR09MB10228: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: YqUlhLfsBYqp9K2+Bj4HjBIHUDU9M9GYwwvy8onhI8F0LSYQEuSJwkTU0uX2uBJJzJvMafFtLBQcfgC7Ra6ReGEc1b5IKakYQXwozcOsViRDnNhvHY8iGUKKnP/p0hQ4vZ/BVq36zno2jrT0HNNFYMe6xCtpnkQuBtDOSOablOdQcVz+pWwzxFmkeyPEnTCwJSSbG/8F1RCxgp+nZnVRVDjJOITG1x2jl8shvURQJHnfJDAYL92E8jrR45Dnugr/Fj5UUUkIUiJTJ1W9Olwo59H5pt95D6LVBkZ742dwHPBd6fsXi9W3mK4uPVOuud9w/Behbup83gONsHfqL0/PAV7azQ/E9vJPy+OcbLjD7PBEGaVO9qMnEbRFK45BdZUVDJQi/utfRDe896AR93ft01jBkIb1jGIZA14HAxj0jzq8K9NN1/OGYuSPxKLkFwZYPCjcabeuujSMmD3xW9IYbcNJLJWNqQzsW0dxvcYLlyyn9P4fyc8lmsDAoLiDFeo3QK2x9fTW4yo9c7TzPxlpP3oBsnBc/Sj9z3eyNyuGyqNHL0wFNPyCQRexdXUniSN0bJxTNdj0CaiMlTK9qA2e2xnu0kOGd1b6kwZB1/fGl/g= 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)(1800799015)(366007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?6t5FkSm868akq8TJSRnZUq5oU0ZBZ9d8YS8pHS66M2jxt+cVkCrUxjBN?= =?Windows-1252?Q?pT1DJ29L/dwvyJVThfea0/TrccgTaZtn06YUqsucJACev68Fsd6HDK+A?= =?Windows-1252?Q?2IgJQQnjodJEKNiiwmmyfRnvTx7/DjLwANFSCoDI9LJiDYp+QoLzD80Y?= =?Windows-1252?Q?VLf8wQapuYy3d4o32y+HDKH2kDhNlsBIKb9/ojbuKaxLhvSRQn3gVNd6?= =?Windows-1252?Q?Mkt2vXn3Z/FB1w+wDAssFD5i7I9RTSCyvJSoSkPcNMzPfar5h0NQh/Bc?= =?Windows-1252?Q?eUES8q/tUOxD5JC5DaE2miww8x9+5alhWYy1N1Gg8Mai4V/LIN7kiiVV?= =?Windows-1252?Q?2NKZuxXMpP+8HhSEMrRKp8KUxB+Wm8r1T6Xx/EMcxR7q1a9ky8bIoq5C?= =?Windows-1252?Q?gSgDmtWY8sRxpM++goGTVStVDXJ0CqWEPvwy+oOzyO5fZltXsMlyLF6X?= =?Windows-1252?Q?TgYv2GX4BamIJ3/BB8F9D3Uhl2GUmxH0d3NGcCpR2kqLK7MbsRLheOFA?= =?Windows-1252?Q?PmHwcX9sYUkfM2kFQRSAy4E/ddseRhZY96g1JVF2+AoBGOVsfNKH7VVf?= =?Windows-1252?Q?yz+NaLo95M/B2jG9fMn+FPy/aulw74O0bgbFtiIxDt2vT5Lrh0+7+vC1?= =?Windows-1252?Q?LvGwJAFIb0w/lVhyr11d3Dpacpyp3rc+dWCzsgOlwQskJ8AX1hix5Zwa?= =?Windows-1252?Q?K5/nb38rXo2Nz45g7xzaE5ZC5VhZy7o5trtroipchptzenVXFqooPYMB?= =?Windows-1252?Q?1ZH6AJhrsMsFDm6ioI6EPEQCsZ1OLv7/RJnS07S6CdwNHhbiCeYh4YHA?= =?Windows-1252?Q?NFnwESwAxQV2W+8MpQVEtKuGDka2G1hx12boUklwpS/93aE9QEASzJhi?= =?Windows-1252?Q?/gBtCNGepmITnUV/90//fLYjrjP6VjHCxWxC/0hfk5Tf8bKsiXgNEpVG?= =?Windows-1252?Q?RuM6K5jgcUtvD/wnu9a32yYP4wh2B8N15OD3T49knv+U9tOJtYcCBi/G?= =?Windows-1252?Q?EaT6DIZk3V8Y6viiwruVoxBQpy5bHAPa/Mw3lv80YwOt0DclVEqgEU4+?= =?Windows-1252?Q?JmPnl45ZMjNb+HUuCEZphhrmvjnBMi7+tDx0vmIb39KDTC3G2Zx4C/Ar?= =?Windows-1252?Q?CoiPdk36n5MKj+iX2QXXx1dbRBkkrnLdf3RdAJKXSR96T3bLcsPf3Ozg?= =?Windows-1252?Q?HnnOHZJe/t5+meDUNAWXkYGhUCES9ySnrE0/KQ3/YSRfi7iTKzMtgBK3?= =?Windows-1252?Q?e1cgnbN6I5jRfgFXnZhLjATLlMulhyTXTUYhETkqcUOEH+yHUf4du2jT?= =?Windows-1252?Q?MU/RXwVR5MIZ0tRjPUQPaEZaVpjoCaXHLkde52ntBrtpWtWQ2LONjoZs?= =?Windows-1252?Q?9DEozdFok2Tk6KJcIBmfOQf9tQMy9mYSSauZ8n2ZMK5zFGN8jfmFr/Hu?= =?Windows-1252?Q?YfGyTzVGqVERRJRuy3DLG6PSINv5PcuGem3xsjj8opGFnlp1rKC0Gg6T?= =?Windows-1252?Q?+DUa0vsbV66xbXWBc8LQGqvIkYS7z5wMbtXRYfluezcMVyTuuP+xjm8t?= =?Windows-1252?Q?bAbHHoCfcQ1lIlPeIPEKzgUZMsFCkwNpwxiQCS2967frjR4axRrU0YrJ?= =?Windows-1252?Q?KOmGmUOdVmALPy3BfCQb/svCMs2fKXNKWVs8oIBh5JdX7YSYz0qelhnn?= =?Windows-1252?Q?5c8ZSzAmii/+fVjV8AZbaVKUBNcs0iotOUjlY+AVLaCK/rpf/NvM6A?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR09MB7385D892200969A3FBBADFE6A63A2PH0PR09MB7385namp_" MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: eQVXNVQshuhWUwQGpgS1mbXHSbg9kaIIgEbjczNEc7+aEREBMZz6F9E2YbDYeXo0DY+2z+MrgR4YGZdqc8RlWvsk39PUbpd/yQU0hnSxynTLXtkjkVFLPFpQrE1VfC9BcvAxNFA+XXvdWOvw7VexkCYWFxSfDAEaX3AIL2RFuTKsKRzQyqILwoTLYTW6pZpoeT+dPWruXsVRRcAWC/JjueADWdtqmzGv01SLjFxgdBxvY12VHDgaj3wSuVQq+jw2GHc+s+hXU4DGC6ZvqF0M0PFgi8qTdxLj6O8O9SN/us+cRuJmXXTqJkMJqd+prheIzlq2o/4PkjOn4XA2NJuiI1pTY9i30LiEjZ5kfMn9UGkU8dPEb7KTvBwVWwjQAilnlg+fBUExEhOPWRf4NtCM8PK7aAH88NDt6qakXhSAZyTLKsSy9YcEktDTVfpcjIgOAPzRfDOtJp62fQ0zr4smYVqkBPRNdPwynIDXL8kuNxMIn8hbAY/M0eEDNVdGdFIP1hlYRIPTZg/ht7F+v7AaQVwA9NeZYPqKW8Bfq10fCiAXWCHEY5FVzFR0Q/EZup65PkurdNg6R9K3gh5/4H9VQpeJKcYS2hMPX3RiSrOqHBo= 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: 0a9a42f1-5683-484e-8b7e-08dc5009097e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 15:58:12.3534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7005d458-45be-48ae-8140-d43da96dd17b X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR09MB10228 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_PH0PR09MB7385D892200969A3FBBADFE6A63A2PH0PR09MB7385namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable But, in this glorious, potentially transient, era where all extant compile= rs have the same storage size for defaults =85 You have the luxury of bein= g able to introduce a non-changing change. I.e., you can spell =93defaul= t integer=94 as =93kind=3D=85=94 and default real as =93kind=3D=85=94. Users would not _need_ to change any code up until such a time as some comp= iler uses different defaults. At which point they will need to change rega= rdless. From: Jeff Hammond Date: Friday, March 29, 2024 at 11:29 AM To: Clune, Thomas L. (GSFC-6101) Cc: General J3 interest list , WG5 Subject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - ple= ase 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. How many lines of MPI Fortran code at NASA would have to be changed if we r= edefine the MPI Fortran API with different types? Changing the MPI Fortran API is not an option here. We either decide that = INTEGER is the same as C int often enough to say that MPI Fortran assumes t= hat and doesn=92t work otherwise, or we end up in what I consider to be a b= ad place. Does anyone believe that the MPI standard should support e.g. promoting onl= y INTEGER, in violation of the aforementioned part of the standard, or that= MPI should support DOUBLE PRECISION that is 128-bit? Jeff On 29. Mar 2024, at 16.49, Clune, Thomas L. (GSFC-6101) wrote: External email: Use caution opening links or attachments 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. =B7 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_PH0PR09MB7385D892200969A3FBBADFE6A63A2PH0PR09MB7385namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

But,  in this = glorious, potentially transient, era where all extant compilers have the same storage size for defaults =85  Y= ou have the luxury of being able to introduce a non-changing change.  =   I.e., you can spell =93default integer=94 as =93kind=3D=85=94 a= nd default real as =93kind=3D=85=94.  

Users would not _need_ to change any code up until such a time as some compiler uses di= fferent defaults.  At which point they will need to change regardless.=

 

 

From: Jeff Hammond <jehammond@nvidia.com>= ;
Date: Friday, March 29, 2024 at 11:29 AM
To: Clune, Thomas L. (GSFC-6101) <thomas.l.clune@nasa.gov>
Cc: General J3 interest list <j3@mailman.j3-fortran.org>, WG5 = <sc22wg5@open-std.org>
Subject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6574] Fortran type size= s - please help with MPI Fortran

CAUTION: This email originated from outside of NA= SA.  Please take care when clicking links or opening attachments. = ; Use the "Report Message" button to report suspicious messages t= o the NASA SOC.



How many lines of MPI Fortran code at NASA would have to be changed= if we redefine the MPI Fortran API with different types?

 

Changing the MPI Fortran API is not an option here.  We either= decide that INTEGER is the same as C int often enough to say that MPI Fort= ran assumes that and doesn=92t work otherwise, or we end up in what I consider to be a bad place.

 

Does anyone believe that the MPI standard should support e.g. promo= ting only INTEGER, in violation of the aforementioned part of the standard,= or that MPI should support DOUBLE PRECISION that is 128-bit?

 

Jeff



On 29. Mar 2024, at 16.49, Clune, Thomas L. (GSFC-6101) <thomas.= l.clune@nasa.gov> wrote:

 

External email: Use caution opening l= inks or attachments

 

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<= o:p>

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= explicit kinds.

 

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

 

=B7         Tom

 

 

 

From: J3 <j3-bounces@mailman.j3-fortran.org> on behalf of Jeff Hammond via J3 <j3@mailman.j3-fortran.org>=
Date: Friday, Marc= h 29, 2024 at 10:33 AM
To: WG5 <sc22wg5@ope= n-std.org>
Cc: Jeff Hammond &= lt;je= hammond@nvidia.com>
Subject: [EXTERNAL= ] [BULK] [J3] [SC22WG5.6574] Fortran type sizes - please help with MPI Fort= ran

CAUTION: This email originated from outside of NASA.&= nbsp; Please take care when clicking links or opening attachments.  Use the "Report Message" button to report sus= picious 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, LOGICAL and REAL; 32-bit DOUBLE PRECISION and COMPLEX i.e. NUMERI= C_STORAGE_SIZE=3D16

b.      32-bit INTEGER, LOGICAL and REAL; 64-bit DOUBLE PRECISION and COMPLEX i.e. NUMERI= C_STORAGE_SIZE=3D32

c.      64-bit INTEGER, LOGICAL and REAL; 128-bit DOUBLE PRECISION and COMPLEX i.e. NUMER= IC_STORAGE_SIZE=3D64

d.      <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 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.361= 5319 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 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 libr= ary on top of C.  Bill Long has said he thinks is a good thing, and wh= ich I have partially = implemented in order to give MPI Fortran broader compiler support and more complete featu= re 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 ecosyste= m, 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 askin= g 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 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_PH0PR09MB7385D892200969A3FBBADFE6A63A2PH0PR09MB7385namp_--