From owner-sc22wg5@open-std.org Tue Nov 11 10:52:52 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 65936C178D9; Tue, 11 Nov 2008 10:52:52 +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 A5F78C178D6 for ; Tue, 11 Nov 2008 10:52:50 +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]:40191) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1KzpvV-00076h-51 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Tue, 11 Nov 2008 09:52:49 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1KzpvV-0004eY-Hb (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 11 Nov 2008 09:52:49 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 11 Nov 2008 09:52:49 +0000 Date: 11 Nov 2008 09:52:49 +0000 From: "N.M. Maclaren" To: WG5 Subject: N1755: Request for new features from MPI Forum Message-ID: In-Reply-To: <20081111092010.7FFB8C178D9@www2.open-std.org> References: <49137AD3.1070402@lrz.de> <20081110124449.AEBF1C178E0@www2.open-std.org> <20081111030258.C9550C178D9@www2.open-std.org> <49193B79.8030807@lrz.de> <20081111083358.6613AC178D9@www2.open-std.org> <20081111092010.7FFB8C178D9@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 Here are a few comments on this. > 1. A mechanism to suppress copy-in/copy-out semantics for MPI > asynchronous operations. That's not enough. I can't remember whether any compilers actually did it, but Fortran permits arguments to be passed using Jensen's device, as well as copy-in/copy-out and reference. And it is VERY likely to be used if VOLATILE coarrays are ever supported on systems that use message-passing for communication. > 2. Suppress argument checking for MPI choice buffers (C void * formal > parameters). There is a better solution, but I am not sure that we could get there starting from here. Some languages allow types to be passed as procedure arguments. > A series of straw votes were taken at J3 meeting 184 to determine how to > address the request from the MPI Forum. The results were: > > 1. The VOLATILE attribute should be given to both the actual and dummy > arguments to suppress copy-in/copy-out. Ugh. Don't bet on it working reliably, anyway. Why should it? What the standard says is something entirely different. > Regarding straw vote 1: > > A problem with using VOLATILE attribute is that it > can have performance implications. Therefore Aleksandar Donev in paper > 08-255 proposed the following: > > We should explicitly allow a variable with the ASYNCHRONOUS attribute to > be modified or examined by means external to the processor, similarly to > VOLATILE variables. If such a variable is modified or examined externally > during a segment, that variable must not be referenced or define during > that segment. That will introduce performance implications, though perhaps less serious. But I really don't like the idea of having to teach kiddies about coarrays when they want to learn MPI. What is actually needed is a way of allowing user code to set and clear a variable's pending state, in the sense used in 9.6.4. While it would be a bit tricky to add to Fortran, it would be semantically clean, and be as efficient as possible. And, of course, it should be a separate pending state, with the same semantics, but incompatible with I/O proper. 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