From owner-sc22wg5@open-std.org Thu Nov 6 01:01:40 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 56536CA343A; Thu, 6 Nov 2008 01:01:40 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 343 seconds by postgrey-1.18 at www2.open-std.org; Thu, 06 Nov 2008 01:01:39 CET Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id 9EF2FCA3434 for ; Thu, 6 Nov 2008 01:01:39 +0100 (CET) Received: from mh1750-1.us.cray.com (mh1750-1.us.cray.com [172.31.74.55]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id mA5Ntr5k026873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Nov 2008 17:55:53 -0600 (CST) Received: from mh2650-1.us.cray.com (mh2650-1.us.cray.com [172.31.74.50]) by mh1750-1.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id mA5Ntroi025074; Wed, 5 Nov 2008 17:55:53 -0600 Received: from mh-dhcp-172-31-16-226.us.cray.com (mh-dhcp-172-31-16-226.us.cray.com [172.31.16.226]) by mh2650-1.us.cray.com (8.13.8/8.13.3/spool-5907) with ESMTP id mA5NtpWq011795; Wed, 5 Nov 2008 17:55:52 -0600 Message-ID: <491232EE.1000504@cray.com> Date: Wed, 05 Nov 2008 17:57:34 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: sc22wg5 Subject: [Fwd: Re: (j3.2006) Preparing for the Tokyo meeting] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Reposting to the WG5 list... N.M. Maclaren wrote: > While that is true, multi-user (shared) systems are NOT going away, and > parallel applications are a right b*gg*r to schedule on such things. > Really? All of our systems are configured as multi-user (shared) systems, and run parallel applications almost exclusively. Job scheduling for multi-processor systems (including vanilla clusters) has been a solved problem for years. > Some administrators forbid them, and jump had on users caught running > them. I can understand an administrator jumping on users for running serial codes on a cluster, on grounds that they are wasting resources since they can run codes like that on their desktop machines. The problem of an administrator who bans parallel jobs from a parallel computer is probably handled best by the (un)employment office. Certainly not an issue for WG5 or J3. > But, in many more, they cause trouble to other users and/or run > very badly (including taking many times as much CPU as they need). > Badly written programs is a programmer training problem. I would expect coarrays to actually help since they (in my experience) are easier to use correctly than MPI. > So serial Fortran will not go away any time soon, and some people will > positively want coarray-free compilers (or a fixable mode). > > I agree that having a compiler switch that allows the user to fix num_images at compile time (to 1, for example), or to disable the recognition of coarrays entirely, is a fine vendor feature. That gives the user freedom to live in a serial-only world. It is also explicitly outside the scope of the standard (1.3 Exclusions, page 1). Having a separate compiler that cannot deal with coarrays at all seems like a bad idea on two grounds: for the vendor there is added cost to test two different compilers, and for the user the need to keep two compilers around for the day when he discovers modern computers (or wants to use someone else's program that employs coarrays). > > Er, the vast majority of Fortran users have never USED or even SEEN a > vector machine (and, no, I don't count SSE etc.) You have, and I have, > but the kiddies - including post-docs here :-) - I teach never have. > Some have never even HEARD of them! > > Sorry, but SSE does count. And if you write your codes to vectorize well, you get better performance even on commodity processors. This is basic programmer training. Where are these people (not) learning how to program? This is not really an issue for the Fortran standard, but it sounds like computer science / programmer education generally is in a shocking state of disrepair! (With some notable exceptions, like John Wallin, who are working to correct the problem.) Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120 -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120