From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri Mar 29 15:33:20 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 C2C0E356DF0; Fri, 29 Mar 2024 15:33:20 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2110.outbound.protection.outlook.com [40.107.223.110]) by www.open-std.org (Postfix) with ESMTP id 1ECE3356D94 for ; Fri, 29 Mar 2024 15:33:19 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W314Q9vlUMmbs+jPYEOw9pSW5w8yrReMA3Mwjo7xp1Zxy2UDJDjlEEtLd7B04P8tuu9afkb+BmuN4u2c3B+VSr4gMetu7F/tRoqKl8/BbiBk5l36nmI99LI3aX+VxpxEr72g+YsraHUtRntrBDp7ydnQmFMrAwIp2rzwoyq4feKMbPgqnn/YpkKKjZ8v7xas7hkw8lSN4wzR2j2Ne+mp1onIUBKeoE4NI42Og45dpSLlG1cpucwK5BpBr9/fVEIflKUs25kbTt1P917Ggma0ybaUYlr+8G05lIO3RzKinJa9WnOzpRf/VigUvy51rr/Wp29retV8bN2C+SLLTZVGCQ== 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=TUhFDjNuynqPhtnthwLUPFNQOg/wkmBYhLFGD3c+iyY=; b=femuJvuD6GwHtTv6W7uRpLflG+AxTgi0qKl63bmtcCxQfiyIb3jFVHX+BOwW62kbjYgTtjjso0n5yxeVRs6/sHMuT3Ca/P1LVakPKkOW5Nrt7S/dajMvJTtYFvveX/bf5Oyth23zgStoJMRg+oA4Fv+5ojUxe+pcOVpclA4AQ7oBVVFnJTSIsGmBRwn1Mvt9zw9Hd1PdfKpyOe5lXn381HIYjQJK9A/2IDh+P50rE8OHPMcnYKj3T5oibSq5/q4IGcOnnIINm/cua7gfIrLLHwrNOyJN0siUBKYiN8Zbg7QYjkfDEnSpoefjsIu0pMNMLPnZBnAUt3kW2MaGZCTjtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TUhFDjNuynqPhtnthwLUPFNQOg/wkmBYhLFGD3c+iyY=; b=BlFFlLNuaKs20RXib+1JML4kVyWzZ1yU/q/DLaAULiQtxC9GjxlQMLqIaIDoaIg9r8erYnAbS5uJHmNfZlcIJknNBCM+IYHcgr0kV1URxBlk2TxIuJTHZrekvLseMkDaZn7YzDTzrIKpIJ5aH+ddmiEbaKfjvcG53oN458ySNyGcVbvA7LdR+4OhoToerqmTlzQXcXxbppLEun7J3ScUhPMc6gGowtd1lFQREUPpHwj6Ew4Qk+3NvsszBBfSsU33UkO+mHiLBwOQB3kK8Bkn0uIHZ8x3ChqNNCsH+Ed6B4BGQz3AEGsEpWGb1ZWFbBWhYx2l0N31vrCN5drP3ap09w== Received: from DM6PR12MB3130.namprd12.prod.outlook.com (2603:10b6:5:11b::16) by DM6PR12MB4313.namprd12.prod.outlook.com (2603:10b6:5:21e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.39; Fri, 29 Mar 2024 14:33:12 +0000 Received: from DM6PR12MB3130.namprd12.prod.outlook.com ([fe80::3b3e:8b99:dc87:e5b3]) by DM6PR12MB3130.namprd12.prod.outlook.com ([fe80::3b3e:8b99:dc87:e5b3%5]) with mapi id 15.20.7409.039; Fri, 29 Mar 2024 14:33:12 +0000 From: Jeff Hammond To: WG5 Subject: Fortran type sizes - please help with MPI Fortran Thread-Topic: Fortran type sizes - please help with MPI Fortran Thread-Index: AQHagcIPXHcNYSj5h0CgOXx8WJHTJw== Date: Fri, 29 Mar 2024 14:33:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR12MB3130:EE_|DM6PR12MB4313:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fzIJrKGRJJ64Bzde6tfBpAIgvwOC00Wb6s2hXnvsoSYBXUwr3G1qhkYCP0wgbzUCUM++0KnOk3fxYmPB6lmmpqRq9zo38HUEw1hWZfjk1i0RHwy3hAngVuYqMTPNJfMBKyD6NYrUXevNmjzCrpiKsgmcUyRU0LHvRKrhBbPUvtXgVeU4Ethtf7cJO5NQjSFbGmgj+fn0hUHUgjJF+ha3X1MfTk//BbF3KM91obiQBQz67T0EwUfFzc3qGQIV7Aw4mvJHJeqojXRfvTRvUR2jBadFBmhfSe8FmJnKEMUpg2ralR89+7XPplJkShD5T+rA21xgHJMjJIC5I3D70DcQMO4zE/tOtMqnqqVAh8tJKJDq85tRwdQQqfdKmiSdU/A+Rwzv8rCONWkHgv6/7YtqPBiR7/yeCGk4lj+tLyJa1Se6Q0yK5A3rJw/as0Z9FKcdjqYFae9E+bmFjrgzSzYdeL354XMaox1ycSJ0TQWg4nHDVhucjbef4vz7cPLmc4l1I7ZXWtzzRX7FiuxzuXsLXk5kVwV1Yo+eYJnQWU6eJI/jd3dWrVJ68ySt/NqwQfJbzBkCHzg65Yd9d4Rtsxh5UuaMobnqJar58oMWQKLX63g= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR12MB3130.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?zUaDFRhi+2sgNTv0a0RINNH1c4ZhYPBJUHuCbNjJwVx/VoN/9dZMU9p4?= =?Windows-1252?Q?/+vJy12f0oU/c2qkH9Dmw/WhYhvlEjYSVqv9AniDfb0kLfbF7Odumpsn?= =?Windows-1252?Q?CXKiJZUZRLAauWDPq8ofzEG5vQMJjU7a4VqT0Qyvkd3HRUx2cib5yNWF?= =?Windows-1252?Q?TAokNSBjZeuTVLKXcWw6nnJuFNr67fptnlNTnCZpSqUiIuw0vaF8Q5JX?= =?Windows-1252?Q?uD8qusl4DOHYSEYvGxZM1Nl8E5PZmHcPsZNaM9A5doWtYVnDMpxUvKDB?= =?Windows-1252?Q?xSZMoWxzl6zbx9z1RYit1yxF00ZnyPfAk74OhOYIfAZGsIyuU9abtQLp?= =?Windows-1252?Q?BedpurC3Xi5ZMNtiIp0nXXeSlbW9h5pWYXA+5Ch/XE4L5/LOAAWXikQF?= =?Windows-1252?Q?WkQ8gNPi+acND8tao/18sQGb6iH8hYQPQfLP2V2PMIXUAtwtSXjgmIue?= =?Windows-1252?Q?BWgUQ/sHsBh47s9/xVCvtaDgWLTioAqM4rIYUS0jw6pWxCP5TFOI5Bas?= =?Windows-1252?Q?R7+3BKWgj4QJM7KduDA6zlVu204X+kYlJsrLjxsagWl/+FKY1qIY6+vM?= =?Windows-1252?Q?H+q1ftOUg4DDfJ0NF4cJhdii7E3dwChzIPA6ReWKem0wfCYB4cigM/qX?= =?Windows-1252?Q?VjHYfqjbHhUtYtLo3iSQbk3i1ZxXAUSl4Innn8YH3lP2+lYRRrZU+NEx?= =?Windows-1252?Q?lnnoucp4PC1rW6qtpDulARLVplcsDFYgBEFNcSFDT5G0XR7JTJHjCNQG?= =?Windows-1252?Q?22eEb8WQLEGrGQcfkanwxFvx9kPD3xp8UnpwnZRleQpO8RQFK0r7VRfi?= =?Windows-1252?Q?4QLywwYGK6broq41ZNuwPY+mAuKdLarQORuIuWuLc5ApTx7NRmwOfG4v?= =?Windows-1252?Q?iaUQnzAgJJz0c7olb7nZfZINvXtW7h9PFs8AVSuxJ9qL5B4G1UMLs/rv?= =?Windows-1252?Q?fQGw3kUycWfAHH//0Y9AlTahaCsTF/kEIMH8dWd9tG0e0k+tvbTGjCWw?= =?Windows-1252?Q?xAVSkzr4Hf4DaxylklfuH5Rv0ZzL9Hu+AENoHyRrZAWLVJs0aQm8b4cW?= =?Windows-1252?Q?WGyxjlcEGC8z/vkIu93/Kl01QsyMzFLFzWnKGJ0e81pRB1jXXvxRhIEV?= =?Windows-1252?Q?F73MffsSpQepv1H3CvIIt38uTx38F1BGUAU9AhxXWWWLiLPTYsH2Uq3v?= =?Windows-1252?Q?eSDNatzdyRRF6uhk/jJuOzgnEzmDMJ71RvBOsyN77NPzwHsyTkyOxYVa?= =?Windows-1252?Q?Xgh6wcbEQVHJuSmSR6mpe215PEZZ79ewLE9dYRf0M+r14iXfx7Z999ZK?= =?Windows-1252?Q?1bZWelXeB0hoJ9om4Pb341AfeqMK6G1O1bVekDRzMd+q5Dt/jW9ywI1V?= =?Windows-1252?Q?eD+ffwlfgSb9KlWtgDwen1QqcPq0qDucRVol8oeiTq7qUht3RyLjVJmR?= =?Windows-1252?Q?1lq2Tv74+73Xqe8SpPar2mFuz71JvQlGTBaNOJCi10j6qJ1byC2OMhM1?= =?Windows-1252?Q?Au0VE/Es/Oxw5KCjOExW1wBSxZbNswXy7v+w5jCQmeVk8Sbp2qf5VxUF?= =?Windows-1252?Q?unIN6/GNiUNOHUi2nAY9O5WOFliX5ShLeW0OamNeQA1a4y8d5Vzr8B21?= =?Windows-1252?Q?KmWe6IUKuBnfaJRWQBoaZif/anL789njdqpIEOhNUD6dpQf8lv26/SM/?= =?Windows-1252?Q?C2OSdANt1shZrH8KULve1lYmThYTlilZ2TK+/Nef9i4eK0mPZ2l5gQ?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR12MB3130E37E952301B9994A9BBBCB3A2DM6PR12MB3130namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3130.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d6f57bf-ab7d-449d-de42-08dc4ffd29ac X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 14:33:12.4029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5QeRQGniwv7TqJtLxUo99/oYDrQHq96z6zbSpL0jawC+hpbZbzfaMho6Of0tizDY3nJiC5Jwxa5KVNUN+zuQPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4313 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_DM6PR12MB3130E37E952301B9994A9BBBCB3A2DM6PR12MB3130namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: 1. 16-bit INTEGER, LOGICAL and REAL; 32-bit DOUBLE PRECISION and COMPLEX= i.e. NUMERIC_STORAGE_SIZE=3D16 2. 32-bit INTEGER, LOGICAL and REAL; 64-bit DOUBLE PRECISION and COMPLEX= i.e. NUMERIC_STORAGE_SIZE=3D32 3. 64-bit INTEGER, LOGICAL and REAL; 128-bit DOUBLE PRECISION and COMPLE= X i.e. NUMERIC_STORAGE_SIZE=3D64 4. 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_DM6PR12MB3130E37E952301B9994A9BBBCB3A2DM6PR12MB3130namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Per = 19.5.3.2 Storage sequence, the following default type sizes are possible, a= ssuming that type sizes must not go outside the ranges defined in ISO_FORTR= AN_ENV:

  1. 16-bit INTEGER, LOGIC= AL and REAL; 32-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE= =3D16
  2. 32-bit INTEGER, LOGICAL and REAL; 64-bit DOUBLE PRECISION and COMPLE= X i.e. NUMERIC_STORAGE_SIZE=3D32
  3. 64-bit INTEGER, LOGICAL and REAL; 128-bit= DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D64
  4. <things th= at violate the cited text of the standard>

 

I am= not aware of any platform used this century that supports (a) and only kno= w 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 d= ifferent from a platform ABI and defined in terms of how MPI types compile on a given platform).  We do this i= n 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, an= d so forth.  Specifying these definitions means that implementations of the MPI C API are interoperable at the share= d-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 Fortr= an remains a first-class language in MPI.  However, some members objec= t 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.

 

T= he MPI Forum will ultimately decide between (b) and nothing.  In this ca= se, nothing means that Fortran datatypes and C-interoperability routines wi= ll 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 c= ase 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 platfor= ms, e.g. x86 still doesn=92t have native FP16 for REAL in (a) and no platfo= rm 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 bet= ter than no choice at all.

 

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

 

I=92= ll note that we won=92t take anything away from MPI Fortran with implementa= tion-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 exp= ect 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 implement= ation of MPI Fortran support.

 

My f= ear is that if I cannot convince the MPI Forum to standardize the MPI ABI t= o include Fortran support in the C library ABI, that Fortran will become ev= en 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 ha= ven=92t been used for decades like Fortran has.  The alternative desig= ns to my proposal add significant overhead to MPI Fortran versus C or break Fortran use cases in minor ways (apparent= ly, breaking =93a few=94 Fortran codes is acceptable to the MPI Forum if it= means they get to spend less time thinking about Fortran).

 

I ap= ologize if this is not entirely clear.  This is a wildly complicated t= opic and I=92ve spent about 3000 hours getting to this point, so at some le= vel you all will have to trust than I am distilling this topic down appropriately.

 

Than= ks,

 

Jeff=

--_000_DM6PR12MB3130E37E952301B9994A9BBBCB3A2DM6PR12MB3130namp_--