From owner-sc22wg5@open-std.org Wed Jan 21 23:12:43 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 75689CA3434; Wed, 21 Jan 2009 23:12:43 +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.0.111]) by www2.open-std.org (Postfix) with ESMTP id 60AD2CA3432 for ; Wed, 21 Jan 2009 23:12:41 +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 n0LMCa0M027977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jan 2009 16:12:36 -0600 (CST) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n0LMCYJS022084; Wed, 21 Jan 2009 16:12:35 -0600 Received: from mh-dhcp-172-31-16-180.us.cray.com ([172.31.16.180]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 16:12:34 -0600 Message-ID: <49779E7F.8010009@cray.com> Date: Wed, 21 Jan 2009 16:15:27 -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: MPI-3 Fortran working group Cc: WG5 Subject: Re: [MPI3 Fortran] MPI non-blocking transfers References: <49775A9D.3080102@cray.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2009 22:12:34.0909 (UTC) FILETIME=[5CC128D0:01C97C15] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > > > Firstly, it can happen in plain code, and at least some compilers do (or > used to). For example, consider vectorisable loops on possibly > non-contiguous or vector indexed arrays. A compiler is perfectly > entitled to copy more than it needs to contiguous workspace and copy > both the updated and untouched locations back, if the array is not > marked ASYNCHRONOUS and is not otherwise used. The reason is typically > alignment (as in many vector systems, SSE etc.) I assume the memory involved is the MPI buffer array. If the user has vectorizable code that references the array, and the processor hardware cannot handle non-stride-1 vectors, then it might make a copy. (More likely it would just load the upper and lower halves of the vector register with separate instructions, but for the sake of argument, suppose not.) But it certainly would not do a copy back, since that data was never modified. If the code is storing into the buffer array, which would require the copy back, then this is certainly a user error. The user is not allowed to write code the clobbers the buffer between initiation and completion of the MPI operation. > > Secondly, merely passing an argument does not count as a modification, > even if it passes an array section to an assumed-size dummy (which > forces copy-in/copy-out). Right, it does not count as a modification. That is exactly why this is the problem that we have to solve. It is not covered by the 'thou shall not clobber' rule imposed on the user. > This can apply both if the call is an > extraneous one, and when the call is an intermediate level between > where the buffer is defined and the MPI call. Agreed. But this is also the case for asynchronous variables in Fortran. So we do have some guidance on how proscribe coding requirements on the user. (Assuming it is allowed to force changes to existing codes.) 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