From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri Mar 29 21:13:03 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 C384D356DFB; Fri, 29 Mar 2024 21:13:03 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2100.outbound.protection.outlook.com [104.47.64.100]) by www.open-std.org (Postfix) with ESMTP id 24D3A356DF2 for ; Fri, 29 Mar 2024 21:13:01 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/NMRaqOjDDyS/wYQpPNRMaVfXp8sI3uRS61pO8JflcoTjkDcTDBt/jcd9Ppa8gosWGclTIJb4k2DVIbeOBwaWsszQi3RGWW24tNG1k8P5Ldt/z1ResxBcmjEH8jiA9WDtlEGEoXb0FVOxytwUc5G4oX9LiFCutyGJCzsEcaosw5AKzIHbBnU+9VbgpRh0Lx89Y2ToFS3y41jDyiiO2vz+EAnCe9C2gSRKcREd4lBoTy5OFXZgL5UeUYOQB9aobF0QqRYH3rKAO7dPyl8HRgucAQouODhfrf2w815UEwBxXIi2NPCULG/fFy/jeGKmA2gmTTXaXwOdimN3ImymfYfA== 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=FAT1HAdyVEO0ld7wb0QtBW56YbZdv5wBwgTU1uVnJIA=; b=hfpeqaVL/5B+ayq5U8UNBmf+0fcjbmF/kKfwLB8asw3Gt69j7Zfr2IWlKCj9KZuaxedAtE8AqcQBPboxsZ9xNOoVLIhKeI/BdpQftL+9qt8LDyGGbpq2EBEDkwmt/YHpKbeRxYbQ9sA86jQ5fV9319k81tSqt0WVASr2bdCGobKDG3fS8hqdLN1WaWTztU9HSLOC3J55LS7ZkEu1nGVcdqS/pzCGPYm1mJUzBo8UsV6lkPepgG9MlmcdvM8lkFgW1q9oVbxBFbJpr7HOiDWhN2YL0QyFSrphh+mCC70Nm/uKccKZ4rjo+MtNiXJvXgfvJbEZADKx7MbdcTNGSWT+jQ== 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=FAT1HAdyVEO0ld7wb0QtBW56YbZdv5wBwgTU1uVnJIA=; b=kAx4EILKQuwf6TgJpN2kNNBm1MSlM5o46gzFnFTJjdrSv2DmsJINER5+BhrWEF5oD1Idp4PakIqfrAQYUysJHKQx5vIl0UekEkDvbyoWA3+bTQDjy9Co8+5H/K5Sd966EG0bLMIGaW2xRfvjy3ijGL+S3sOSG480LgOwX+bGnMw= Received: from PH0PR09MB7385.namprd09.prod.outlook.com (2603:10b6:510:62::18) by SJ0PR09MB6381.namprd09.prod.outlook.com (2603:10b6:a03:268::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.42; Fri, 29 Mar 2024 20:12:59 +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 20:12:58 +0000 From: "Clune, Thomas L. (GSFC-6101)" To: General J3 interest list CC: Jeff Hammond , WG5 Subject: Re: [EXTERNAL] [BULK] Re: [J3] [SC22WG5.6580] Fortran type sizes - please help with MPI Fortran Thread-Topic: [EXTERNAL] [BULK] Re: [J3] [SC22WG5.6580] Fortran type sizes - please help with MPI Fortran Thread-Index: AQHagf74Mqmt2i9F6UiMyCGNWnANaLFPJeSs Date: Fri, 29 Mar 2024 20:12:58 +0000 Message-ID: References: <20240329145655.E8CFB356DD2@www.open-std.org> <1DFBC5F5-0300-419B-AD1D-C49E73E066A9@nvidia.com> <20240329163220.70189356DEF@www.open-std.org> <98E4FF9B-7BFF-445D-BFAD-C0B5BB6BEDFD@nvidia.com> In-Reply-To: <98E4FF9B-7BFF-445D-BFAD-C0B5BB6BEDFD@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_|SJ0PR09MB6381: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: YohdoGPY1CGA5/lJMeL/AZB92pgs9KNeOD7ckVkD4fBNJrP4QBez1s523g7RX3U28hDpkUUXx/v8/lZm1TqTbN5lXzGQnte8MpZei6oFDvQb4TaimkK0hSTSGZ40a3m67yEp8kGSeQYfAp92ELDyIZKZI9ICt7e8P7HfSn3P6xdamVg92SPqZptEPVwljt1TrXTGaecRX+UVf5MMKW0NyiPrAHXm/MPUHpUMM5jVAls6uqH+rwRlFvwra0QLdpPRD1Sg9aOY+FbzZ7XCNUk348cwV/CKi2mu5TTMqzssmMY7tqUv49ixBX+pRRlTk5Mdcgs/8DPNpPE34eaJwfCd0G6WiB6qngWathWNktu19Cyf+HXTCFa9arJULPJyf5HHu1+L8F/4Szgep0vb/4hGKE6rL9OcPOXUm0LP9xUOMzDV8ef7En1/qFasOLgi7oHRjie/TG9h8zkOmxFWr5peaZ041ApHfO+tmtTs5OTvy1+hgO1ILVLqhXHJn38xSCdXzU4CmvZW41kArrNcfbmETXDSFLpObxLx8o1ei7LE9ssK4XUMXmqYTrUovbDPse1qWtZx6UquHIwlcqziPRPDmADrpZkwMNfaPMoCyz30XUA= 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?rTrO4zujw6JC2PXapawTCtS47Et/d9QB7AIk0BtoNak+ydFVbDSOIQRS?= =?Windows-1252?Q?Ldug3e6cKwIMVq6z2IjPE83jplNKQa44aXAOCIHzMgdu4a/tLEjkq86k?= =?Windows-1252?Q?lUIN8kSeuv+112lZQrUI/2htKO/Iq/yY9h+zKaDVle9H6j4AySSRc9K5?= =?Windows-1252?Q?YxF1CVEgGbJ37JNvsHB7I8JKdhcRCU9nVWJFb5j3dh3N8+sH1S1ruViy?= =?Windows-1252?Q?T5c2i9/9AKGyoGPKH8hGVhs2zNRN0xo1gZvyIWqorZ0pq3AHl8IQiwph?= =?Windows-1252?Q?w5BPYO0q9RL/M418g8ObXwr4w2MVCYfYIDxDKmy12wq3Xs5uevm75bHr?= =?Windows-1252?Q?VAN3oW0QISeJj1OpKWmZAmg8Wb9G57lnfqlfTSermI/LO/QFJk5BZ0x5?= =?Windows-1252?Q?ob35I7SVoBI1SfB+MsB87M+WaV4pXHuBSaFEnLpl6jbc9QWz4BQkn5A0?= =?Windows-1252?Q?2GyPZX1xMZoMbPZVrrNrps+mFglIF6F7EmlckBvo4reDgEgKdn+a5g33?= =?Windows-1252?Q?r9TDxXMaQqZGxqaj62gEyD7qJf8NxeYM5s3M/r40uqnvC4tpFjxT0jCF?= =?Windows-1252?Q?RpoqJzEHgKGgYLnkYOJBvo4f51aDn9JsIDVqqNMLvfOpNJIKTPHLlkGQ?= =?Windows-1252?Q?qyxJzFEml3lNoZthVuNIxvSHPHxMEdAMsvc158S0L1vRP4PaakpeIo86?= =?Windows-1252?Q?9aiCLzrj16vRYnYE9mrxZnNhdo9SoB/TeUY8MnSEiAjw3GdzQF4GmH8D?= =?Windows-1252?Q?BJr8KGfvCbbB3Z91j6wUQjVx5KnUsvZgADYPMq/Z0SQ7A99haENe7Kdi?= =?Windows-1252?Q?Q5eZidFMq5h1GtUbE3d0chTonBZ6yYWHK33XBgrrO37bcAWLZl8FhJZd?= =?Windows-1252?Q?Gw/t410a89jbHvfgGFs2qmZaD2MLm1mB5GrnlOqEUJcW/jtlrl88zmHG?= =?Windows-1252?Q?SdJ0RqaN0jFU4zb/bbrwi9L5rN2BGz32wriSnRXYM6onID1wiZQFSV9I?= =?Windows-1252?Q?9bhoPJjltAMF9JT0N2HiUL4hxUFhrlzvSGpvMT82+OmEqfev1PPYkR+I?= =?Windows-1252?Q?08y2Qx1uoRXXnOkTT0CC78olubKUPBVfoeS5GwZN9y4g65DtKai2aATF?= =?Windows-1252?Q?JwI3sFW2HDfrVcBkTMV55T3D50KaJIjKPpaoPcQItoAKvuPao2oIrffI?= =?Windows-1252?Q?dhp44wF8DzO3pmIjgg7WcsjN5M/j8b6vj/PlAKGJfanDiUSehdBZ2h7e?= =?Windows-1252?Q?BkXhloUELVnMB6K2fTXYSf6spR/lwAlZpI5zWKYahtYcmDPeCK6reS8M?= =?Windows-1252?Q?y3M8MM4UMSUickuReEIaqnD55TQvjrdDKAv1UaHC5s/838A74adgqjVe?= =?Windows-1252?Q?6VegKdzS+JMeo7+60/8tuKAMfvvRNxOdme9+YFmZo+80bHz/D+3Ruvei?= =?Windows-1252?Q?h2e0WznXW5aQZLPIf8rf44N8nEx/qDuwVR6foSAsUVSgSV+YXvXN65kt?= =?Windows-1252?Q?Nvl4g3o0Pf428tLSUKSi+xlFsIVTE6M/5TH+PZnP1CFWGBr+kocUnShi?= =?Windows-1252?Q?qCkL3G3B9+U3ogxjcXuDBjiD21PF9xbr9U7JO9bI851RvQ+ZHxcDFy2r?= =?Windows-1252?Q?B+DabviVgQkvn18+bJBu+ZPLmC0qRCXZALr/R3JdpFISwGt1QnzEUniw?= =?Windows-1252?Q?RJRSXDA+NDw1DPy7aE7hPXkpuEf/90DDuAJw2w4rNvvufnPVgBJb2g?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR09MB738551E30E88F25E228ABB8AA63A2PH0PR09MB7385namp_" MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: q6L9i3rc4tA9+wNeo5alET7SSAYXeZwkoR6XAoSRtIuv8Sjvb0TqJOqrhq4phr8cRmiksNY7wTMATXyqfzxv9sOfPCDlUqeiMwksKvZ5Yg85pMwjzv4sFvpfms4CmLB1hmQHRqcyM36HiusXUOgFGUck8MlWOJDAIEDki82V1+bU37TTgW4KBWomMGBv9oxx4rZsvanxi4VJ2Qix9ehXTpAdoDE7Ppx7xdqVjPWUnN+cQfgtjT+OQMxzTbhwWJhUJF1PQhVa0TUUB3QDr4NaNA7o2Up7lNjz99se2OPTs96MrRGuAo4GHUr8FGJgvtjHGvbzxafiC2uBvXkYhkL7XdFnLWyZklwWTdHiAxNjrI5OIr9Mx7JPkxwJT8zlHYzpVETNr2mGHnjBzQTrM4g2GvBYjCHSqdzGf7GGaFrHF4cRqEiOXGm7h0uW/uECFap1LXJPwWxaEqV8vD3iAwQLOBknqbpt12ZWLkmW0iGpIGv8uh5+HhRiRq633ySBXg0DS4frUX1P6AJ4QThu567DKJ+jtfdHgEfCYJKEY4OTNvxHA3mwnbPHTRBOymRrXMW00egewlddvylihNlVMEtUFCMB8mGy9p836UKp4b4Pn6Y= 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: 3be2da28-7a75-44b5-ac42-08dc502ca0ea X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 20:12:58.7721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7005d458-45be-48ae-8140-d43da96dd17b X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR09MB6381 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_PH0PR09MB738551E30E88F25E228ABB8AA63A2PH0PR09MB7385namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Still not seeing the problem. If MPI today supports -i8 then the library i= s overloading for 2 kinds of integers. So the MPI Standard would need to d= efine (at least) 2 specific KIND parameters for those use cases. =93-i8=94= does not override explicit declarations that use KIND=3D. Again, no ex= isting code will break. This _is_ what it means to spell out the MPI API for Fortran in a platform = neutral manner. * Tom From: J3 on behalf of Jeff Hammond via = J3 Date: Friday, March 29, 2024 at 1:31 PM To: General J3 interest list Cc: Jeff Hammond , WG5 Subject: [EXTERNAL] [BULK] Re: [J3] [SC22WG5.6580] 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. Sadly, there is nontrivial use of the non-conforming -i8 option in the worl= d today. While that code deserves to be broken, I am not going to be the o= ne to break it. The issue for me is that MPI has an API that we are not changing. The ABI = effort aims to specify the types that are currently left as opaque/unspecif= ied. We have consensus for how to do that in C. My problem now is that we= do not have consensus on how to do that in Fortran, since there is a depen= dency between MPI typedefs and the default Fortran INTEGER kind. Changing = this has been proposed but it breaks API backwards-compatibility, so we are= not going to do it. Jeff On 29. Mar 2024, at 18.32, Brad Richardson via J3 wrote: External email: Use caution opening links or attachments Given that right now, in basically all situations, C_INT =3D=3D kind(1), vi= rtually no users' code would need to change. On Fri, 2024-03-29 at 15:24 +0000, Jeff Hammond wrote: The issue is, we have 30 years of MPI Fortran code that does things that ar= e correct according to MPI and Fortran, but which are broken if we do certa= in 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=92d have ze= ro problems, but ISO_C_BINDING came a decade after MPI was created and Fort= ran 2003 compilers weren=92t widely available until well after 2003. Jeff On 29. Mar 2024, at 16.51, Brad Richardson via J3 > 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 a= t 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 defa= ult logical occupies a single numeric storage unit, > a nonpointer scalar object that is double precision real or default compl= ex occupies two contiguous numeric storage units, means that option (a) would be non-conforming. Somebody feel free to correc= t 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. M= y guess is >90% of users expect it already. Question though, why would it n= ot make sense for the MPI Fortran interfaces to be specified in terms of th= e C equivalent kind parameters from ISO_C_BINDING? That way if C_INT /=3D k= ind(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 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 MP= I 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 more co= mplete feature support than they can get from MPICH and Open MPI today. Th= e other issue is that it makes MPI Fortran less usable within the MPI ABI e= cosystem, 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_PH0PR09MB738551E30E88F25E228ABB8AA63A2PH0PR09MB7385namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Still not seeing th= e problem.  If MPI today supports -i8 then the library is overloading = for 2 kinds of integers.  So the MPI Standard would need to define (at= least) 2 specific KIND parameters for those use cases.  =93-i8=94 does not override explicit declarations that use KI= ND=3D.     Again, no existing code will break.

 

This _is_ wh= at it means to spell out the MPI API for Fortran in a platform neutral mann= er.

 

  • 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 1:31 PM
To: General J3 interest list <j3@mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond@nvidia.com>, WG5 <sc22wg5@open-= std.org>
Subject: [EXTERNAL] [BULK] Re: [J3] [SC22WG5.6580] 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.



Sadly, there is nontrivial use of the non-conforming -i8 option in = the world today.  While that code deserves to be broken, I am not goin= g to be the one to break it.

 

The issue for me is that MPI has an API that we are not changing. &= nbsp;The ABI effort aims to specify the types that are currently left as op= aque/unspecified.  We have consensus for how to do that in C.  My problem now is that we do not have consensus on = how to do that in Fortran, since there is a dependency between MPI typedefs= and the default Fortran INTEGER kind.  Changing this has been propose= d but it breaks API backwards-compatibility, so we are not going to do it.

 

Jeff



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

 

External email: Use caution opening l= inks or attachments 

 

Given that right now, in basically all situat= ions, C_INT =3D=3D kind(1), virtually no users' code would need to change.&= nbsp;

 

On Fri, 2024-03-29 at 15:24 +0000, Jeff Hammo= nd wrote:

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

 

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

 

Jeff



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

 

External email: Use caution opening l= inks or attachments

 

Hi Jeff,

 

I believe that

 

> The decimal precision of double precisio= n 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 th= at holds a default real, default integer, or default logical value

> a nonpointer scalar object that is defau= lt integer, default real, or default logical occupies a single

numeric storage unit,

> a nonpointer scalar object that is doubl= e 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 di= sclaimer about that for Fortran users. My guess is >90% of users expect it already. Question though, why would it not m= ake 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 /=3D kind(= 1) at least the compiler will yell at you about it.

 

Regards,

Brad

 

On Fri, 2024-03-29 at 14:33 +0000, Jeff Hammo= nd 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:

a. &= nbsp;    16-bit INTEGER, LOGICAL and REAL; 32-bit DOU= BLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D16

b. &= nbsp;    32-bit INTEGER, LOGICAL and REAL; 64-bit DOU= BLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D32

c. &= nbsp;    64-bit INTEGER, LOGICAL and REAL; 128-bit DO= UBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D64

d. &= nbsp;    <things that violate the cited text of th= e 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 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 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_PH0PR09MB738551E30E88F25E228ABB8AA63A2PH0PR09MB7385namp_--