From owner-sc22wg5@open-std.org Sat Jan 24 13:07:05 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 5E918CA3432; Sat, 24 Jan 2009 13:07:05 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by www2.open-std.org (Postfix) with ESMTP id BE9E2C56CFB for ; Sat, 24 Jan 2009 13:07:03 +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]:41480) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1LQhHx-0006IR-KN (Exim 4.70) (return-path ); Sat, 24 Jan 2009 12:07:01 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LQhHx-0002bo-9g (Exim 4.67) (return-path ); Sat, 24 Jan 2009 12:07:01 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 24 Jan 2009 12:07:01 +0000 Date: 24 Jan 2009 12:07:01 +0000 From: "N.M. Maclaren" To: MPI-3 Fortran working group , WG5 Subject: Re: [MPI3 Fortran] (j3.2006) (SC22WG5.3921) (SC22WG5.3917) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <497A9910.6090904@llnl.gov> References: <49776DF7.1040900@cray.com> <20090121211748.130A5C178D9@www2.open-std.org> <20090121224014.6CB63C178D9@www2.open-std.org> <20090121234200.4F3BDCA3434@www2.open-std.org> <20090122000407.D5A8ECA3434@www2.open-std.org> <1232658808.15119.824.camel@math.jpl.nasa.gov> <20090123095622.CBD80CA5FED@www2.open-std.org> <20090123190515.A5B24CA5FE6@www2.open-std.org> <497A1CE5.3000708@cray.com> <20090123204209.615C8CA5FED@www2.open-std.org> <1232747203.15119.979.camel@math.jpl.nasa.gov> <497A51B9.3080304@cray.com> <1232753543.15119.989.camel@math.jpl.nasa.gov> <20090123234036.9C7A4CA5FED@www2.open-std.org> <497A9910.6090904@llnl.gov> 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 24 2009, Aleksandar Donev wrote: > >> The real question is whether "keep rewriting your code until the >> compiler accepts it" is a "solution" to the MPI group. Realistically, I >> think it is the where we'll end up. > >As Nick said, no one can fix broken code. If code passes a non-contigous >array to an MPI routine that cannot handle that, and copy happens, >nothing can fix that but changes to either the code or making a run-time >error in an MPI wrapper (since the routine cannot handle it---and a >compile-time error is much better than a runtime one). Likely the code >would never work correctly to begin with, so it does not sound like a >good reason to change MPI to me. Agreed. All competent MPI/Fortran courses teach their attendees not to do that, already, because it doesn't work and can't be made to. >Remember that ANY of the actually technically-feasible solutions >includes adding some attribute on the buffer array. These are not there >in existing codes. The codes will need to be changed. Bill has mentioned >some sort of implicit acquisition of said attribute but that still >smells fishy to me. Nobody has proposed any way that any of the other 'solutions' would percolate up multiple levels of call; a 'solution' that works only for one or two levels is no solution at all. If you look at real MPI codes, a large proportion have multiple levels between the MPI_Isend and the MPI_Wait. >The only actual problem is that existing constraints for asynchronous, >for a good reason, require that the actual be "simply contiguous". This >is more restrictive than "contiguous". There may be codes that rely on >"oh it will work cause it is contiguous", but to make it simply >contiguous that may require code changes (e.g., adding the CONTIGUOUS >attribute here and there). All of these are nontrivial especially for >people that do not really understand the meaning of these attributes. Yes :-( However, if there are improvements possible, they could and should also be applied to Fortran asynchronous I/O. 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