From owner-sc22wg5@open-std.org Mon Oct 26 17:04:03 2009 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id F15DDC178E4; Mon, 26 Oct 2009 17:04:02 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.62.100]) by www2.open-std.org (Postfix) with ESMTP id 3AFFDC178E3 for ; Mon, 26 Oct 2009 17:04:01 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n9QG3wfn025684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2009 11:03:58 -0500 (CDT) Received: from cfexcas01.americas.cray.com (cfexcas-2.us.cray.com [172.30.74.227]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n9QG3vcS013192; Mon, 26 Oct 2009 11:03:57 -0500 Received: from fortran.us.cray.com (172.31.19.200) by cfexcas01.americas.cray.com (172.30.74.226) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 26 Oct 2009 11:03:56 -0500 Message-ID: <4AE5C892.8050603@cray.com> Date: Mon, 26 Oct 2009 11:04:34 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: fortran standards email list for J3 Cc: SC22WG5 Subject: Re: (j3.2006) (SC22WG5.4122) [ukfortran] Parallel random numbers References: <20091020154252.946EAC178E3@www2.open-std.org> <20091021161933.1B2FCC178E3@www2.open-std.org> <20091021171501.21FA4C178E3@www2.open-std.org> <20091021175702.E4D26C178E3@www2.open-std.org> <20091022043326.83DB9C178E4@www2.open-std.org> <20091022051613.0AEF5C178E4@www2.open-std.org> <20091022062554.CF066C178E4@www2.open-std.org> <20091022115243.E875EC178E4@www2.open-std.org> <20091022160201.90187C76BB7@www2.open-std.org> <20091022172236.755B9C76BB7@www2.open-std.org> <20091023215253.78206C76BB7@www2.open-std.org> <20091026130908.E4F6BC178E1@www2.open-std.org> In-Reply-To: <20091026130908.E4F6BC178E1@www2.open-std.org> 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 N.M. Maclaren wrote: > On Oct 23 2009, Robert W. Numrich wrote: >> I agree with Aleks: >> >>> 1) All the sequencies are independent >>> 2) The same random number generator is used on each image (same seed, >>> same sequence). >>> 3) No restrictions on calling RANDOM_SEED and RANDOM_NUMBER ala ordering >>> of segments. >>> If the user wants to get different sequencies on different images, just >>> use different seeds. No quasi-independence or any such quality >>> guarantees---this is to be used in simple tests, debugging, student >>> codes, and for certain algorithms where the quality does not matter much >>> (for example, random alternation algorithms in linear-algebra algorithms >>> or even some PDE grid solvers) > > There are two issues there. > > 1) The first is that the examples are too optimistic; while the > quality doesn't matter much, the association is often SO bad that it > causes even those algorithms to give wrong answers. Yes, I have seen > that, quite a few times. I believe that Aleks meant by (1) that each image maintains a separate sequence, and is not proposing that they are statistically independent of each other. By (2) I assume he means that the default seed is the same on each image - clearly the user can change the seed independently on each image if desired. > > 2) Are you really saying that the Fortran standard should REQUIRE a > known, deficient approach, of a nature that every expert in this area > regards as unacceptable? That's not the Fortran I know. > This is how every MPI program works today. >> Making things "proceesor dependent", as suggested below, is a bad idea. >> If the programmer wants some special random sequence, he needs to generate >> it himself. If he is serious about random numbers, even on a single >> processor, he should generate his own and not depend on some compiler >> generated sequence with no known properties. > > That is the converse advice of what every expert has said since Knuth, > and all still say today. > Usually claims to speak for "every expert" are wildly overstated, as is clearly the case here. Bob's statement is exactly what the serious user has been told for decades. > While I agree that very few vendors have a clue about this area, At this point the pompous condescension has gone just too far. Vendors, contrary to claims, are not idiots. We know that the simplistic linear congruential generators that are normally supplied do not represent quality generators. They are supplied because of market forces (i.e. customer demand) require that the generator be as fast as possible. If the people who decide the requirements for machines change to wanting a slow, but higher quality generator behind RANDOM_NUMBER, the vendors would certainly change. > ordinary programmers have even less clue. They are likely to pick up > some catastrophically bad generator from the net, because there are so > many more of them than competent ones out there. > > > The point here is precisely that coarrays are based on a SPMD model, and > not a MIMD model. There is a single program, and not a collection of > independent images - that's the MPI model. > I really don't understand that statement at all. Fortran 2008 and MPI have the same SPMD model. Indeed , we fully expect to have mixed coarray and MPI codes. E Each image does execute independently most of the time, just as with MPI. 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