From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Jul 9 10:45:43 2013 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 A2268356F49; Tue, 9 Jul 2013 10:45:43 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1299 seconds by postgrey-1.34 at www5.open-std.org; Tue, 09 Jul 2013 10:45:43 CEST Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by www.open-std.org (Postfix) with ESMTP id 1754F3569C1 for ; Tue, 9 Jul 2013 10:45:43 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38037) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1UwTDA-0000Xi-DN (Exim 4.80_167-5a66dd3) (return-path ); Tue, 09 Jul 2013 09:23:48 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1UwTDA-0005GQ-16 (Exim 4.72) (return-path ); Tue, 09 Jul 2013 09:23:48 +0100 Received: from [91.125.173.108] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 09 Jul 2013 09:23:48 +0100 Date: 09 Jul 2013 09:23:48 +0100 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.5025) Canada's national body report to WG 9 (Ada) Message-ID: In-Reply-To: <20130708210335.C0094356938@www.open-std.org> References: <20130708210335.C0094356938@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 8 2013, Van Snyder wrote: > >Canada's national body report to the recent WG 9 meeting in Berlin >remarked that WG 14 and WG 21 "are making significant progress towards >the model and implementation of support for massive parallelism (many >cores) within their languages." That is extremely dubious. Massive parallelism was not part of WG21's objectives in the original design. As is usual, however, a partial success has led to euphoria and hubris, and some people are claiming that the current model is scalable to massive parallelism. Others are more realistic. >"In addition, Canada believes that there should be a language >independent model of massive parallelization (data-level parallelism and >control-level parallelism) that underlies the work going on in >individual languages. Yes, I know - they aren't the only ones :-( It will merely obstruct progress - in exactly the same way that POSIX has obstructed threading progress. It's difficult enough to match language concepts, but matching different parallelism models has never been done successfully, as far as I know. The next paragraph would imply that the objective is interoperability for everything from distributed memory message-passing models (MPI and descendents of Smalltalk) through virtual shared memory and PGAS to tightly-coupled explicit threading (C++) and implicit threading (parts of OpenMP, CilkPlus, X10 etc.) Oh, and let's throw dataflow (Prolog, VHDL and probably some more general languages) into this, just to keep things from getting too simple! The killer with what people usually mean by many-core (GPUs) is that their architectural model is different from what modern multi-core CPUs have turned into - though possibly not different from what they will become by 2020. And that is even more different from networked processing (Cray etc.) > The justification for this is that virtually every >system or application built today consists of multiple languages linked >into a common image. To effectively implement any level of parallelism >in such a system requires that a common and compatible approach be >followed. To this end, Canada is proposing to SC 22 for its plenary in >September, that SC 22 form a study group to determine if the creation of >such a model is possible and if so, how it can be achieved and what the >best vehicle would be to progress such work. We ask that WG 9 and WG 9 >p-members be supportive of this initiative." The trouble is that such study groups very rarely, if ever, return negative recommendations. One can hope, but I am not optimistic. >Since Fortran has apparently taken the lead with coarrays, it might be >worthwhile to mention coarrays in this context, if the topic arises at >the SC 22 meeting. Yes. Regards, Nick Maclaren.