From owner-sc22wg5@open-std.org Fri Nov 7 00:39:08 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 6669ACA5FE8; Fri, 7 Nov 2008 00:39:08 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by www2.open-std.org (Postfix) with ESMTP id A3864C178D6 for ; Fri, 7 Nov 2008 00:39:06 +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]:41547) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1KyERO-00015j-4a (Exim 4.70) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 23:39:06 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KyERO-0007YT-D8 (Exim 4.67) for sc22wg5@open-std.org (return-path ); Thu, 06 Nov 2008 23:39:06 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 06 Nov 2008 23:39:06 +0000 Date: 06 Nov 2008 23:39:06 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.3643) (j3.2006) A comment on John Wallin's comments on Nick MacLaren's comments Message-ID: In-Reply-To: <20081106232341.ABD83CA343A@www2.open-std.org> References: <20081105225653.DCEA7CA3428@www2.open-std.org> <20081105232803.42621CA3434@www2.open-std.org> <20081106232341.ABD83CA343A@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, Bill Long wrote: > >> Most of the users I have dealt with have backed off shared-memory >> paradigms when they found that they couldn't debug or tune them, and >> gone back to MPI. The problem is that there are, and can be, no tools >> to trap race conditions. > >This is, of course, one of the main arguments in favor of coarrays. The >programming model, is SPMD, as with MPI, which experience has shown to >work, and to be the most popular. Shared-memory models, like OpenMP, >do have their place, but have limitations. Not at all. Coarrays are almost indistinguishable from OpenMP in this context. The debugging problems were caused by race conditions in shared memory accesses, which are impossible in MPI if you avoid using non-blocking transfers in open code. And the killer was the lack of any tools to detect them. Both apply to coarrays. The tuning problems were caused by similar conditions, but with false sharing replacing race conditions, and the inability to put instrumentation into the communication. Again, the same is true for coarrays. >Deadlocks introduced by the implementation should be reported as bugs to >the vendor. Unless the standard makes it clear whether the programmer or implementor is at fault, that is merely a waste of time. MPI goes to great trouble to specify what each of them is required to do, and that is a major reason for its reliability and portability. 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