From owner-sc22wg5@open-std.org Thu Nov 6 20:32:55 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 6AD7FCA5FE8; Thu, 6 Nov 2008 20:32:55 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 454 seconds by postgrey-1.18 at www2.open-std.org; Thu, 06 Nov 2008 20:32:54 CET Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by www2.open-std.org (Postfix) with ESMTP id 2877DCA343A for ; Thu, 6 Nov 2008 20:32:53 +0100 (CET) Received: by rv-out-0708.google.com with SMTP id c5so785666rvf.34 for ; Thu, 06 Nov 2008 11:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=jrixWpC53axkqtWAN4sCncmhhLJou5qBeT4GPA1CLHM=; b=NkhonXYr/mYb1BClUYgtrjglglw5KeNXZPp98zFhtiImo1jNMzHI9ZCWGRGb5FxUza n9xEMoyGwVsqVkyOSVHRVDpwai3LQqQOZlFJoVuAHdOHhaXq8RGE5uWlqPVQCOInYnoq LNOQQahOSsfduTF30duiYSIbiIKB4pYMBME1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=Kwx2v0qOOmRPX+GXEH0CAAzvnbj5FuLo1WcwYRWU+5YLLdRXPy3WD6NBWXLqIHNhRf JJFbM+C945Y/rMML7NmNTIXqKNHO9vKnXeC74BKrtqm5TPiUQGEE0cRkW/qtP5ddi0C1 ReEk22G9BYt7F9gO/toA8UDg1ro74UE36C4+8= Received: by 10.141.74.18 with SMTP id b18mr1397920rvl.208.1225999519175; Thu, 06 Nov 2008 11:25:19 -0800 (PST) Received: from ?192.168.100.25? (c-75-70-187-168.hsd1.co.comcast.net [75.70.187.168]) by mx.google.com with ESMTPS id f42sm2590947rvb.6.2008.11.06.11.25.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Nov 2008 11:25:18 -0800 (PST) In-Reply-To: <20081106084230.BD64BCA343A@www2.open-std.org> References: <20081106000140.7BDFCCA3434@www2.open-std.org> <20081106084230.BD64BCA343A@www2.open-std.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <398AA79A-08A6-4037-BFBB-DC544C195B37@gmail.com> Cc: sc22wg5 Content-Transfer-Encoding: 7bit From: Keith Bierman Subject: Re: (j3.2006) (SC22WG5.3630) [ukfortran] [Fwd: Preparing for the Tokyo meeting] Date: Thu, 6 Nov 2008 12:25:15 -0700 To: fortran standards email list for J3 X-Mailer: Apple Mail (2.753.1) Sender: owner-sc22wg5@open-std.org Precedence: bulk On Nov 6, 2008, at 1:42 AM, N.M. Maclaren wrote: > > Firstly, most systems have no way to prevent one job from hogging > resources > like memory, cache, TLB entries, and so on. There are rarely any > facilities > to say "give this process N cores or don't run it" or "restrict > this program > to x% of the cache or TLB entries". Most mainframes had very mature facilities. Some Unix operating environments have reasonably good ones (google solaris resource management containers). > > Secondly, the thread schedulers are almost always optimised for > interactive > (GUI) work, Tunable on the better systems. >> ..... > > You are assuming that the world is like Cray. It isn't. I am > referring > to the multi-core systems that are used for mixed workloads, of the > sort > I describe above. And, yes, I managed Cray-like systems for a > decade, so > I can talk both languages No doubt many institutions don't segregate jobstreams in a sensible fashion. And doubtless there are reasons for their behaviors (good, bad, non-technical, etc.) but precisely how does that translate into what should be part of a Standard? > ... > 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. It should be possible to configure the runtime so that only N images can run ... and N could be 1. While that might not provide the clearest programming style, what's the issue for a Standard? > .... b) Because of that, SSE optimisations are handled by all > compilers in > simi No doubt more to come in the not so distant future. Indeed, some people have noticed that today's graphic processors are attached processors in the rough style of the FPS array processors of yesteryear. Where there are compute engines there will eventually be people trying to exploit them ;> But that also seems to be a bit of a digression from the question of the advisability of adding coarrays. If they aren't "everywhere" (for some reasonable value of everwhere) and committed to be in future products, most people won't be able to make the investment in coding for them. So make them part of the standard, or throw them off the train entirely. The middle ground is largely an empty wasteland. > -- Keith H. Bierman khbkhb@gmail.com | AIM kbiermank 5430 Nassau Circle East | Cherry Hills Village, CO 80113 | 303-997-2749 Copyright 2008