From owner-sc22wg5@open-std.org Thu Jan 22 21:08:56 2009 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 908BBCA5FED; Thu, 22 Jan 2009 21:08:56 +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 C3FF7CA3439 for ; Thu, 22 Jan 2009 21:08:53 +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-2.csi.cam.ac.uk ([131.111.8.54]:56285) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1LQ5rA-0007Ig-5y (Exim 4.70) (return-path ); Thu, 22 Jan 2009 20:08:52 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LQ5rA-00063K-R3 (Exim 4.67) (return-path ); Thu, 22 Jan 2009 20:08:52 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 22 Jan 2009 20:08:52 +0000 Date: 22 Jan 2009 20:08:52 +0000 From: "N.M. Maclaren" To: WG5 , MPI-3 Fortran working group Subject: Re: [ukfortran] (SC22WG5.3898) (j3.2006) [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <20090122195243.07B19CA3432@www2.open-std.org> References: <200901221111.01710.donev1@llnl.gov> <4978CB93.2050609@cray.com> <20090122195243.07B19CA3432@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 Jan 22 2009, Aleksandar Donev wrote: >On Thursday 22 January 2009 11:40, Bill Long wrote: > >> The only safe thing for the >> compiler to do is treat array as volatile throughout the subprogram >> containing these two calls. > >No! For ASYNCHRONOUS, there is a restriction on the *programmer* that if >array is referenced/defined, it is not currently a pending I/O >affector. This is the same as for coarrays, which may make things >clearer: If a coarray is defined/referenced, the compiler can fully >optimize without worrying about other images, *in-between* >image-control statements. The same logic applies for >ASYNCHRONOUS---optimize unless you see a WAIT. Note however that some >of the optimizations Nick mentioned should also be disabled for >coarrays. Notably, a piece of a coarray that is *not* >referenced/defined in a segment *may* indeed be referenced/defined by >other images. So the optimizer must not touch those pieces, even in >what would be harmless ways in a serial code. Yes, precisely. >For a classic (serial) optimizer, ASYNCHRONOUS and coarrayness and >threading and all of those things are essentially the same: Something >else, which is not included in the classic control/data flow analysis, >can store/load certain values, which are marked in some sense (via >CODIMENSION/ASYNCHRONOUS/VOLATILE attribute). Do you think all coarrays >are effectively VOLATILE??? If not, then the same applies to >ASYNCHRONOUS variables. Again, precisely. 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