From owner-sc22wg5@open-std.org Thu Nov 6 22:08: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 55E99CA5FE8; Thu, 6 Nov 2008 22:08:32 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id C435DCA343A for ; Thu, 6 Nov 2008 22:08:31 +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]:55353) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1KyC5f-0004GO-0M (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 21:08:31 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyC5f-00021z-3G (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 21:08:31 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 06 Nov 2008 21:08:31 +0000 Date: 06 Nov 2008 21:08:31 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3641) (j3.2006) [Fwd: Preparing for the Tokyo meeting] Message-ID: In-Reply-To: <20081106205049.B488ACA343A@www2.open-std.org> References: <20081106000140.7BDFCCA3434@www2.open-std.org> <20081106084230.BD64BCA343A@www2.open-std.org> <20081106193255.89EFECA343A@www2.open-std.org> <20081106202630.CFE6FCA343A@www2.open-std.org> <20081106205049.B488ACA343A@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, Keith Bierman wrote: > >> ...Linux is no different. The solution is usually the one >> mentioned above >> (i.e. give the gang-scheduled software enough cores that you don't >> cause >> conflicts with other applications). > >And keep the jobs that need gang scheduling on a "machine" (virtual >perhaps) of their own with a batch scheduler and no interactive jobs. Agreed. That's what I did (after my experience of not doing it with IRIX, when I was new to managing large SMPs). >I disagree. As far as I can tell, nearly all programming language >standards make the implicit assumption that they own the "machine". >It's is the OS's job to make that illusion real enough (except where >some "volatile" asynch service is taking place that the application >wishes to consume ;> Yes and no. The problem is when a language assumes an operating system model that isn't near-universal. If anyone thinks that Fortran has enough weight to swing major operating system redesign, they are living in cloud cuckoo land. >Coarrays should be a lot easier to deal with (code for, port, etc.) >than MPI. MPI has proved useful across a variety of implementations >despite having a weak foundation. Coarrays are a step forward. They >probably aren't the last step; but it will be years before we get >"there" and we probably won't if we don't make stepwise improvements ;> That is a matter of opinion, but I don't intend to debate it - but please note that I am not saying that coarrays (except for VOLATILE ones) are a step backwards. They have advantages and disadvantages over MPI. 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