From owner-sc22wg5@open-std.org Fri Nov 7 11:18:32 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 5D011CA5FE8; Fri, 7 Nov 2008 11:18:32 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by www2.open-std.org (Postfix) with ESMTP id 68387CA343A for ; Fri, 7 Nov 2008 11:18:29 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50660) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:nmm1) id 1KyOQ9-0002Ma-Nt (Exim 4.70) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 10:18:29 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyOQ9-0005Tn-Co (Exim 4.67) for sc22wg5@open-std.org (return-path ); Fri, 07 Nov 2008 10:18:29 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 07 Nov 2008 10:18:29 +0000 Date: 07 Nov 2008 10:18:29 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.3644) [ukfortran] A comment on John Wallin's comments on Nick MacLaren's comments Message-ID: In-Reply-To: <200811061616.22916.donev1@llnl.gov> References: <20081105225653.DCEA7CA3428@www2.open-std.org> <20081106232341.ABD83CA343A@www2.open-std.org> <20081106233908.84C89C178D6@www2.open-std.org> <200811061616.22916.donev1@llnl.gov> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk Obviously, I agree with Aleksandar on this, but here are a few minor details. On Nov 7 2008, Aleksandar Donev wrote: > > This kind of thing plagued and still plagues array syntax: Nice syntax is > great but if it cannot be intuitively mapped onto performance there is a > problem. Indeed, yes! One of my colleagues was VERY unhappy at the code generated by every compiler he had access to - it was the amount of clearly unnecessary argument copying and the dire performance of MATMUL that were the main issues. Things have improved, but I still spend some time on this when I give even an elementary course. At least, with array syntax, I can explain in fairly simple terms when the code will almost certainly be efficient, when it almost certainly won't be, and when it will depend on the compiler and options. And back much of that up with references to the standard. > However, Nick's > example (I paste it from e-mail below since the WG5 site is not working > for me), it not that clear cut. I think mixing in the example about the > spin loop in this discussion is a sidetrack---the example and explanation > pasted below is IMO more illustrative. But, to reiterate the statement, nobody is claiming that the restrictive implementation I refer to is likely - the question in that example is only whether such a processor is conforming. And I can guarantee that few (if any) users will think that it is, but I can't find any wording to say that it isn't. > What Nick and I seemed to agree on is listed below as our "intent". > Please consider this carefully instead of endlessly arguing about > job/thread schedulers. Yes. I have to accept blame for diverting the issue. Sorry. > As a worst-case scenario, consider running n_images=2 as two threads on a > single CPU with a single core. It seems reasonable users may want to do > this for debugging, unless we warn them against it. Should we? The way that schedulers come into it is that it is fairly common for a program on a shared multi-core system to be run in that mode, either because of affinity issues or because the other cores are tied up with higher priority tasks. So it ISN'T just a problem for old machines. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679