From owner-sc22wg5@open-std.org Thu Nov 6 21:50:49 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 954D5CA5FE8; Thu, 6 Nov 2008 21:50:49 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.243]) by www2.open-std.org (Postfix) with ESMTP id 7D058CA343A for ; Thu, 6 Nov 2008 21:50:47 +0100 (CET) Received: by rv-out-0708.google.com with SMTP id c5so821407rvf.34 for ; Thu, 06 Nov 2008 12:50:46 -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=R2uOgufkcVa5sYa/KQUvEVPZdURGyDQ++MYWNFoUmyI=; b=Vzw1mUoRrM5YWSr6PzL5OUEDI8vbHS/Q+uzWVf9w120LEJKi6KvXPPKMH6Q48grOYK QLLIrxddQptscY3hFbzGY0XsvZFmLeYogsh9VdDje1PQUhpmEBHgGOBihcSE8EqVSq8M bsx2Ki2oBBikGwa9jF938Jee1Fn2XDD6eYjWE= 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=OvHz5Gm5DRXLswinFllSYKYmmq3wy2BfVUV5XVnR342+jV+LWZkF+VXo8ZwmhOnrJo lP1YqFtbvIYp0wI6oayZI4iZl0PVA6ULs1Jb/xGVfqmNWO/WluFFyf+txeuM6fN3Z+eW dH+L4Qgcqhc8RObkue9sAK3pVbxRGSVObZEKY= Received: by 10.141.162.1 with SMTP id p1mr1448126rvo.87.1226004646462; Thu, 06 Nov 2008 12:50:46 -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 b39sm2739850rvf.0.2008.11.06.12.50.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Nov 2008 12:50:45 -0800 (PST) In-Reply-To: <20081106202630.CFE6FCA343A@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> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00BDE569-D7D1-4CD8-9973-D139B9CD75F5@gmail.com> Cc: sc22wg5 Content-Transfer-Encoding: 7bit From: Keith Bierman Subject: Re: (j3.2006) (SC22WG5.3639) [ukfortran] [Fwd: Preparing for the Tokyo meeting] Date: Thu, 6 Nov 2008 13:50:43 -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:26 PM, N.M. Maclaren wrote: > > until 2006. Things have evolved a lot faster in OpenSolaris since. > Your statement is true about "give this process N cores > or don't run it", but is NOT about "restrict this program to x% of the > cache or TLB entries" True; I was focusing on the N cores not the subcore facilities. Even where a chip might have such a thing, it's hardly ever in an exposed API that application programmers should count on. > ... > The difference between theory and practice is less in theory than > it is > in practice. True. > ...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. > >> 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? > > Because the standard should not assume such segregation! 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 ;> > > I couldn't care less if unsegregated codes are likely to run like > drains; > that is what any experienced user will expect. But the standard > shouldn't > rely on particular system configurations to ensure that conforming > programs complete in the absence of resource limitations. In > particular, > it should NOT assume them in its examples without saying so > explicitly! We also assume that disks work (data written to disk eventually gets there or if it doesn't it's not the Standard's concern) etc. While I sympathize with your pain as a sysadmin, I don't think that the Standard can or should delve into such matters. There may well be machine configurations which cannot safely run programs that use this feature. Sadly, such machine may be so cheap that people will do it despite the indeterminate results. But that's a question of building (or buying ;>) good systems. > ... > Because many coarray programs won't work if that is done, and > reasonable > users want to know if they are risking coarray-induced failure by > using > such a system. They have to match their code to the system (or the system to their code), one way or another. > > > Oh, yes. I don't disagree that many of those count as vector > processors, > nor that some future SSE replacement may also do so. But, today, > it's got > very different properties. But pretty much the same compiler innards; just with very short vector registers ;> As far as I know, no compiler treats them like they do regular registers as part of instruction instruction and such. Bill and Jim have commented for Cray and IBM. As I am currently unaffiliated, I won't claim to be speaking for any vendor implementation ;> 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 ;> -- Keith H. Bierman khbkhb@gmail.com | AIM kbiermank 5430 Nassau Circle East | Cherry Hills Village, CO 80113 | 303-997-2749 Copyright 2008