From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jul 6 15:06:35 2017 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 12A36357250; Thu, 6 Jul 2017 15:06:35 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id CA902357140 for ; Thu, 6 Jul 2017 15:06:32 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:44477) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:nmm1) id 1dT6UG-0008Mf-Rv (Exim 4.89) (return-path ); Thu, 06 Jul 2017 14:06:28 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1dT6UG-0005ho-Kr (Exim 4.89) (return-path ); Thu, 06 Jul 2017 14:06:28 +0100 Received: from [146.199.130.7] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 06 Jul 2017 14:06:28 +0100 Date: 06 Jul 2017 14:06:28 +0100 From: "N.M. Maclaren" To: "Clune, Thomas L. (GSFC-6101)" Cc: fortran standards email list for J3 , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.5903) (j3.2006) 3 levels of parallelism? Message-ID: In-Reply-To: <20170706122826.F2F333581F6@www.open-std.org> References: <20170705131003.C2A753587D1@www.open-std.org> <677196EB-62B3-448D-8AD9-6D0E36BAFD32@cray.com> <888EAD5C-B10E-4E55-9F63-35F1BBE2F342@nasa.gov> <20170705194923.55D94358633@www.open-std.org> <20170706122826.F2F333581F6@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Jul 6 2017, Clune, Thomas L. (GSFC-6101) wrote: > > As another extreme case, consider why we don't use OpenMP for large-scale > parallelism. There is nothing (or at least very little) in the model that > would preclude using it in a distributed context. But the lack of ability > for the user to indicate memory-affinity and other such concerns means > that the scaling is terrible in almost every nontrivial case. Yes. Intel have just such an implementation, and so we have experience as well as theoretical knowledge. OpenMP is a solidly shared-memory design, and will run like a drain if that is only virtual. Merely indicating things like memory affinity isn't enough, either, because of the number of ways in which OpenMP relies on data being shareable, at least some of the time. > PS Nothing in this message was meant to disparage compiler developers in > any way. They have the task of optimizing _all_ codes and appeasing (to > varying degrees) all customers. I have no reason to suspect they have > done anything other than a superlative job given the daunting difficulty > of the task. Right. This is why the solution is in the languages, and draconian restrictions on things like aliasing are essential - which is also why Fortran still rules in this area :-) Regards, Nick Maclaren.