From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri Mar 29 18:55:22 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 D9F9C356DF0; Fri, 29 Mar 2024 18:55:22 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1940 seconds by postgrey-1.34 at www5.open-std.org; Fri, 29 Mar 2024 18:55:22 CET Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by www.open-std.org (Postfix) with ESMTP id 12189356DEA for ; Fri, 29 Mar 2024 18:55:21 +0100 (CET) Received: from pps.filterd (m0134422.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 42TGXGbq030699; Fri, 29 Mar 2024 17:22:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pps0720; bh=VCI//WxHj91kqhHA1kgRVS3mJu4UPvotN2uGgSFrLWk=; b=niqXgE9NsphGQb0CzTMe6I8S58d3q95Zsrz2WQT/STjf31Y7Sl3q1NbQwjfdOSH6tywk 3tL4z6Vc+XjSCSscUo2CrasaJBYi84gP70V9qRl+CwLqF6IlCDZmEq6fLKyb/F1vuxkU oEng4Dplq6Ho0sK/YB0MkcZSEkPOe42kn+wgfBFJWpIIZ2yFn/5m+z6Wvc9WTzsz6HLh Kqb58K4fNz7fVt3laLsI6SxHWpVvXt5YcRqZP6iNjPe/zuTi+qzFsHe3m6VkvQ0X6rOP KMIqT574mK7Et7jAAvvi2NKZBliOabwIgPodcVW7u3zNEl9BE3v4L1rIcncWUL5rZUyi ZA== Received: from p1lg14881.it.hpe.com ([16.230.97.202]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3x5qsd3um0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Mar 2024 17:22:56 +0000 Received: from p1wg14926.americas.hpqcorp.net (unknown [10.119.18.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by p1lg14881.it.hpe.com (Postfix) with ESMTPS id 0B4EE805EAC; Fri, 29 Mar 2024 17:22:55 +0000 (UTC) Received: from p1wg14927.americas.hpqcorp.net (10.119.18.117) by p1wg14926.americas.hpqcorp.net (10.119.18.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Fri, 29 Mar 2024 05:22:14 -1200 Received: from p1wg14920.americas.hpqcorp.net (16.230.19.123) by p1wg14927.americas.hpqcorp.net (10.119.18.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42 via Frontend Transport; Fri, 29 Mar 2024 05:22:14 -1200 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (192.58.206.35) by edge.it.hpe.com (16.230.19.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Fri, 29 Mar 2024 05:22:14 -1200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PL5Fu7feU7dlk2JRQcB4OVddoUbhHjroQAL5VmpcGLGT51xSWgrOjsK00FJroFR2WPncK/TSIAoW8iXm42S/YTqDZKDLowJa1aEuMhDPXo57HrXo5QYiLtm+XZfI/2Q4n/UAYR2lzsGKsG7PYF8Mr3t7mq5ktkFsRhJfYXH9M5L3N2raegTSbC0kRrvAWANJDiQv5L0r4S0U4M0Vh+3ywnkC0y0JCoOh+AlOdj1X6LPTtIrSu+91Ov5XGZecTtbXxa11rV+pPNec7SROpug65ZZeisNob/WFb4hAt93nFbuIzTAjyPqpgc4fD0djPEZdTl09IrDr846Et0Rg2nXv8A== 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=VCI//WxHj91kqhHA1kgRVS3mJu4UPvotN2uGgSFrLWk=; b=e/dbvGV4QW90rr3++wZMI7tChHsof5IQD+XUisJDI/QLjij2JVM92/tEeej6xywwNklfZscuCDgsXewr31+XYEZYsph24A7FmfwHjMiTqf1adMYyZvSpKQBAaOe4x+wUIGCB7ZukCofTdmavaSqNxBih9kqx8bZ8wqo3HvWaSPpFr2tz4PuETNcjO6nfkolKHFT88XohnU2JgErMzg+95SnR81Ih4KwCqqTNWerQB7EmNfRpLCI6tuyjUczvERfsu/29EKDMn5tOjvwBHZCk7ltYwPsQMnswvub+WZv1DIiF3ljo4lCGuw24uw061+mc8SrXLqV0y/V4+7wnkueoWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from MW4PR84MB1851.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:303:1b2::16) by MW5PR84MB1841.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:303:1c3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Fri, 29 Mar 2024 17:22:12 +0000 Received: from MW4PR84MB1851.NAMPRD84.PROD.OUTLOOK.COM ([fe80::6120:940e:38a3:3500]) by MW4PR84MB1851.NAMPRD84.PROD.OUTLOOK.COM ([fe80::6120:940e:38a3:3500%7]) with mapi id 15.20.7409.031; Fri, 29 Mar 2024 17:22:12 +0000 From: "Long, Bill F" To: General J3 interest list CC: Brad Richardson , WG5 Subject: Re: [J3] [SC22WG5.6580] Fortran type sizes - please help with MPI Fortran Thread-Topic: [J3] [SC22WG5.6580] Fortran type sizes - please help with MPI Fortran Thread-Index: AQHagfbJhlX2uTUOPkKcRcnvPU4YQbFO9B/7 Date: Fri, 29 Mar 2024 17:22:12 +0000 Message-ID: References: <20240329145655.E8CFB356DD2@www.open-std.org> <1DFBC5F5-0300-419B-AD1D-C49E73E066A9@nvidia.com> <20240329163220.70189356DEF@www.open-std.org> In-Reply-To: <20240329163220.70189356DEF@www.open-std.org> Accept-Language: en-US Content-Language: en-US X-Hashtags: #Promotions X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR84MB1851:EE_|MW5PR84MB1841:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OoN2zN/xA8xQj10GqGDUsyYMAZOH8BPkujKmI7/opi5K5aIIBXL7gsT8fgNGSUBp9ave/N0/uYFp08DlwOLCeYYYfLVna+nfSB34rEN95HdQLcRmW6VFKNMo0RKJST9e3iJn2NQDLl6HNItTEKQW5K/FyAK5idLaRCo9iycbvdEswfhT6Bazb0iLhRw3IX6YJQBCMs3bFiprVVH8+CHFT/S924gq4ITx9kKYx2x7ULcMFVxuj8FjPKG8qkNkHOub2ociMR9liwDWM8yCRpmJhfRh+Qn55sGCrbuXa5sGusGTSVXm5bnmLggo24c4kNz6btygKyaBSI2gxBMDnQbqe+K9+9XCu/uJCNXnWIIghMowTCP0Mvw98R8G9Kxxp2e4BLhH96nsHsEQ5rQPfVY7JbW9Am0xwD8MkAyd8rSEi1tusz/X2NfIY9wFjtlCKbJNhxkr2Ukgea0K9eyKPfc0Dlk/Ow7uUmm9E3EUqDGylJ2pSJYz4/C/4zASuZJnRy19ncAiRuVUsa8KcnSF7MeqysnaFDBfsJ2P45nmEumKHFg10xpU0+e/iDlMlvBomr8FzTE+s//wFdlRVLOVoMohLEVERCsxfmsqWXcbnT1LieM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR84MB1851.NAMPRD84.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(1800799015)(366007)(376005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?J87SV6ewXqzzDNb30X1CfwIXibDCv+T2j8JgWG0Kn/rxqSB9ChP5QGCl?= =?Windows-1252?Q?jt0E/izW5nLDD9MMc/xhgaW3IWPBp1+/eSDTPGlTRZLre5QIv2Ru7fZS?= =?Windows-1252?Q?hqEUSpy+4U5TAlt4WLXx3xA5od/Af1SSqEp8+7ZKC4gotjHDIT/HIiOj?= =?Windows-1252?Q?teGQTBYljLQWT83k8rfNOqMsZCIvXsQBmTOOXEQw8xA9/r6Kd+e6a8SP?= =?Windows-1252?Q?UEZ8K8J44hNt3pnvKrn6j9d2rAkHuDDaGFDrUWrH/KKeJhkNu66EDxEX?= =?Windows-1252?Q?/B8pg7jQFFsaOTzHRVw/1QZkqyKK8sJfQuv8zFOLOGKKsxUYVQnZfJmR?= =?Windows-1252?Q?fxQ3wLDxeMcN/nfIv2//+Njcl5xLHOFOuAZIU2+UZl+1TlKCXg5Q1Xjy?= =?Windows-1252?Q?ni9Rjw0NSdd4awKjQIOdGRomZzY9FVlb3hAcOVglOCD2kbqxuyjE4dzE?= =?Windows-1252?Q?DQip5dcGYnFwvv1AwdK8adwFACrQL2Xx7QjdjF/Xt1e74mLRBlw/kzR5?= =?Windows-1252?Q?bBysR86tzKqHYckK+3oznJUagRuHGGFocQhBzWoCukMICq1ZLb6WbnMx?= =?Windows-1252?Q?gzVwbyc3bwYEar/SEO2s1ta+bGhONmm5MMFj7Od3NJehnEkBqZuR4im9?= =?Windows-1252?Q?mIn//Kuh8nH4WKulyK1I06ARn6tS/MREX78bBWrj1uv8136M7EGradsu?= =?Windows-1252?Q?+FIPJd8VAb1N3yYyJyUnXNfE/PfJyvUGeUKjAGlid04ay2LwT9RVmIlS?= =?Windows-1252?Q?GCvcpsKTREGcREBNel0uq2FOz1mA6ceCPXQSXiIhZT58NWuBw6ikspMT?= =?Windows-1252?Q?8GbQWWkCflTuS2QAY6y3UQNN+kU5BewaWgm0xyq/OgIKOsw+kF3n53Ui?= =?Windows-1252?Q?iiXeAJ8sGKo9KBC/TilLMaorHDivrpHUUn9Mra2nD8xQ39UrmdY4oNnJ?= =?Windows-1252?Q?x4FQPhU38tAdr/6BdZdqRuRbyUIr8Hgzy9ukdxcBfWxKBgIwERt8Yfdr?= =?Windows-1252?Q?1wQIF/H2L7jJamO8L/c4CZ94LOslDQs2mNFhuibJW4PXf0Fu8Oz9gAEz?= =?Windows-1252?Q?jkYupYF25JqP9tTW58SkAiIgjRDpPDtCLFkNrrRzbn3vM32iyIStrqep?= =?Windows-1252?Q?qbMzPlaAeCxMAWbIBiltmyreAYab/CxyOEIhSD4n9NuleDfFMw/Jf3hI?= =?Windows-1252?Q?grPQ8tfQJmn9JVMLdz/6kmjxR8G5ReW3t83G0zuo47Bli5D3LtjVXBJV?= =?Windows-1252?Q?kF2qM1k0Iy3WLtq/3uUyrN7tTB/Ys/fz2R8mkWrJVYmY2hbWdpvwoU5V?= =?Windows-1252?Q?J3ZA5iAjF9zOCUV4b9R7H0ltnODsHbz+FWUGIR6G9px53cxt4oMzjK/p?= =?Windows-1252?Q?5+/KYWZNhOlP2vcycAKDAHCJ7wKCdsoRGF/2VW0ZvY+zmNNOw2HkQ1nO?= =?Windows-1252?Q?aYFxYHlo1qvd6Zq0p5KeulPaO6QvOJIardVqz/K6CD1QCTYG8/AGdYWT?= =?Windows-1252?Q?3fmfd8IjSjfHTZS0fcYl4aTwKyInWw7S+pfqcx6dAaAVQI/Tb2vX1jgn?= =?Windows-1252?Q?N3qoRAOcdwTfg3IP/3X0OgwIXUJLeOP/6MZKYSiYVQm+uhsmwATebIqR?= =?Windows-1252?Q?kYpa+or1+PuuclA54yQMxa8x4EzdpwgRGWGtnKY3uzlJw7vHrKFtiCzR?= =?Windows-1252?Q?VY0QxTfgZuU+HjRncaLWr+vD/hEP/47/?= Content-Type: multipart/alternative; boundary="_000_MW4PR84MB185100F2AD139AAE8E648B22973A2MW4PR84MB1851NAMP_" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR84MB1851.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c62d1749-bb48-4d68-5f1d-08dc5014c596 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2024 17:22:12.3915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1R5uzfxy168Vp/I50kueD95sEAJ+e+9kS/2OkOszeFX4kfPBgfKsmug6awgzWvuDSLKP0oijm2TYi39JpLVjtQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR84MB1841 X-OriginatorOrg: hpe.com X-Proofpoint-ORIG-GUID: jYvTiI_AvqtvUU2qPTrhfTsdxbm4tnkL X-Proofpoint-GUID: jYvTiI_AvqtvUU2qPTrhfTsdxbm4tnkL X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-29_13,2024-03-28_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 phishscore=0 impostorscore=0 mlxscore=0 spamscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 adultscore=0 clxscore=1011 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2403290154 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_MW4PR84MB185100F2AD139AAE8E648B22973A2MW4PR84MB1851NAMP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jeff, For legacy codes, in the "old days" having single precision being 64 bits w= as pretty common (and compilers had options to change that). It was a headache to have two separate MPI libraries, one each for the 32 and = 64-bit defaults. More recent codes that use MPI also use the modules and end up calling only= the C routines anyway. Even more modern codes do not use MPI at all since SPMD parallelism is buil= t into the Fortran language. Trying to force option b or c is a non-starter. The MPI Forum needs to foc= us on the C interface and the modules for Fortran users. Cheers, Bill ________________________________ From: J3 on behalf of Brad Richardson v= ia J3 Sent: Friday, March 29, 2024 11:32 AM To: General J3 interest list Cc: Brad Richardson ; WG5 Subject: [J3] [SC22WG5.6580] Fortran type sizes - please help with MPI Fort= ran 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: 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 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_MW4PR84MB185100F2AD139AAE8E648B22973A2MW4PR84MB1851NAMP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

For legacy codes, in the "old days" having single precision being= 64 bits was pretty common (and compilers had options to change that). = ; It
was a headache to have two separate MPI libraries, one each for the 32 and = 64-bit defaults. 

More recent codes that use MPI also use the modules and end up calling only= the C routines anyway.

Even more modern codes do not use MPI at all since SPMD parallelism is buil= t into the Fortran language.  

Trying to force option b or c is a non-starter.  The MPI Forum needs t= o focus on the C interface and the modules for Fortran users. 

Cheers,
Bill

From: J3 <j3-bounces@mai= lman.j3-fortran.org> on behalf of Brad Richardson via J3 <j3@mailman.= j3-fortran.org>
Sent: Friday, March 29, 2024 11:32 AM
To: General J3 interest list <j3@mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional@protonmail.com>; WG5= <sc22wg5@open-std.org>
Subject: [J3] [SC22WG5.6580] Fortran type sizes - please help with M= PI Fortran
 
Given that right now, in basically all situations, C_INT =3D=3D kind(1= ), virtually 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 th= at 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 perspect= ive.  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 ha= ve 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 via J3 <j3@mailman.j3-fo= rtran.org> wrote:

External email: Use caution openin= g 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 defau= lt complex occupies two contiguous
numeric storage units,

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

At any rate, IMO it would be the right choice for MPI to specify optio= n (b) for its "ABI", and have a minor disclaimer about that for F= ortran users. My guess is >90% of users expect it already. Question thou= gh, why would it not make sense for the MPI Fortran interfaces to be specified in terms of the C equivalent kind parameters fr= om 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 Hammond via J3 wrote:
Per 19.5.3.2 Storage sequence, t= he 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 R= EAL; 32-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D16
  2. 32-bit INTEGER, LOGICAL and R= EAL; 64-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D32
  3. 64-bit INTEGER, LOGICAL and R= EAL; 128-bit DOUBLE PRECISION and COMPLEX i.e. NUMERIC_STORAGE_SIZE=3D64
  4. <things that violate the c= ited text of the standard>
 
I am not aware of any platform u= sed 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 sta= ndardizing 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 com= pile 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 ho= lds an address) is defined to be intptr_t, and so forth.  Specifying these definitions means that implementation= s 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/fullH= tml/10.1145/3615318.3615319&nbs= p;has details).
 
I am attempting to support some = aspects of Fortran in the C ABI to ensure Fortran remains a first-class lan= guage 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 Fortran doesn=92t specific (b), but in pra= ctice, (b) is the only standard-compliant choice in use today, and it is us= ed 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, a= nd 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 it= s 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 i= mplemented natively in hardware on many platforms, e.g. x86 still doesn=92t= 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 bi= nary form support either (b) or (d), e.g. Intel supplies MKL for (b) and IL= P64, 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 th= e Fortran standard to specify (b), but I=92m asking for WG5 members to provide me with some support that choosing (b) is better than nothing a= t all, for MPI=92s Fortran users.
 
I=92ll note that we won=92t 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.&nb= sp; However, there is strong demand for the C ABI for many reasons, includi= ng 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 swapp= ing of MPI C implementations, at least.  Fortran modules are not inter= operable, but we can make the MPI C API ABI usable behind a compiler-specif= ic but MPI-implementation-agnostic implementation of MPI Fortran support.
 
My fear is that if I cannot conv= ince 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 s= ame backwards-compatibility issues that MPI Fortran does, because their MPI= support is not standardized and those languages haven=92t been used for de= cades 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 =93a few=94 Fo= rtran codes is acceptable to the MPI Forum if it means they get to spend le= ss time thinking about Fortran).
 
I apologize if this is not entir= ely clear.  This is a wildly complicated topic and I=92ve 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 appr= opriately.
 
Thanks,
 
Jeff


--_000_MW4PR84MB185100F2AD139AAE8E648B22973A2MW4PR84MB1851NAMP_--