From owner-sc22wg5@open-std.org Thu Nov 6 21:39:59 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 8BB6ECA5FE8; Thu, 6 Nov 2008 21:39:59 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id CE8CDCA343A for ; Thu, 6 Nov 2008 21:39:57 +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]:60273) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1KyBe1-0000iB-Hz (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 20:39:57 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyBe1-0006JZ-HS (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 20:39:57 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 06 Nov 2008 20:39:57 +0000 Date: 06 Nov 2008 20:39:57 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3633) (j3.2006) [Fwd: Preparing for the Tokyo meeting] Message-ID: In-Reply-To: <20081106183106.C45D4CA343A@www2.open-std.org> References: <20081106000140.7BDFCCA3434@www2.open-std.org> <20081106084230.BD64BCA343A@www2.open-std.org> <20081106183106.C45D4CA343A@www2.open-std.org> 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 On Nov 6 2008, Bill Long wrote: > >> Firstly, most systems have no way to prevent one job from hogging >> resources like memory, cache, TLB entries, and so on. > >That's a management / policy decision, not a software constraint. >Certainly not an issue relevant to whether coarrays should be in the >Fortran standard. It's actually a hardware constraint. I agree that it is not directly relevant, unlike the scheduler issue, because it doesn't stop programs completing. I shouldn't have responded - sorry. >> There are rarely any facilities >> to say "give this process N cores or don't run it" > >The providers of things like PBS, moab, lsf, ... will be very >disappointed to learn that their products don't work No, they won't. They document precisely that. They rely on the underlying operating system providing such control and, if it doesn't, they don't provide it. And that, in turn, can cause the scheduler problems. >> It's not specifiable. Some coarray programs can survive that >> environment; others can't; and it isn't possible to write a clear >> specification of which can and which can't. > >What is not specifiable? We have a compiler flag, -Xn where n is the >number of images that will fix the number at compile time. That looks >specifiable to me. Sure, if a program explicitly references image 2 and >is run with only 1 image, it will get an error. But that is clearly >specified in the standard as non-conforming. The set of programs that will work with such a constraint is not specifiable. >I can't speak for IBM, Hitachi, or Fujitsu, but at least I know now you >are not aware of what happens in Cray's compiler. I accept the correction. I have never used any Cray system, neither old Cray nor new Cray. 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