From owner-sc22wg5@open-std.org Wed Jan 21 22:17:47 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 E434CC178E0; Wed, 21 Jan 2009 22:17:47 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by www2.open-std.org (Postfix) with ESMTP id 30A56C178D9 for ; Wed, 21 Jan 2009 22:17:46 +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]:60982) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:nmm1) id 1LPkSH-0004ke-Hx (Exim 4.70) (return-path ); Wed, 21 Jan 2009 21:17:45 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LPkSH-0007mv-Hr (Exim 4.67) (return-path ); Wed, 21 Jan 2009 21:17:45 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 21 Jan 2009 21:17:45 +0000 Date: 21 Jan 2009 21:17:45 +0000 From: "N.M. Maclaren" To: MPI-3 Fortran working group , WG5 Subject: Re: [MPI3 Fortran] MPI non-blocking transfers Message-ID: In-Reply-To: <49776DF7.1040900@cray.com> References: <49775A9D.3080102@cray.com> <200901211012.44002.donev1@llnl.gov> <49776DF7.1040900@cray.com> 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 >>>> 2) Most people seem to agree that a data attribute is essential, >>>> and a purely procedure-based solution will not work. >>>> >>>> Do you agree with this and, if not, why not? >>>> >>> The question hints at a common confusion. >>> >> Please answer the actual question. > >I would have if the question were well-formed. It was not. I was just >trying to explain the situation as clearly as possible. I'm looking at >this from a vendor perspective. There are two issues that have separate >solutions. Failing to understand this resulted in some >bandwidth-wasting email recently, and I'm trying to head off more of the >same. Actually, the question is perfectly well-formed, but your (or Jeff's?) answer is wrong, because it doesn't address all of the issues raised by the Fortran standard. >> Answer to question 2 is no---something new is proposed. Are you >> proposing something new or do you prefer an ASYNCH_EXTERNAL attribute? > >I'm open to either approach. This is something the MPI folks need to >decide. Are they willing to have a completely different library >interface for Fortran? Eh? No proposal so far has been completely different. The way that MPI is specified, there is no difference between requiring an ASYNCHRONOUS attribute and requiring and ASYNCH_EXTERNAL one. Both need a minor change. >> Or maybe you prefer not to do anything at all (i.e., ignore the issue). > >Considering that people have been using MPI with considerable success >for a very long time, that is one option. However, the discussion >presupposes that facilities to reduce possible user problems are >desired, so either you accept the premise or drop out of the discussion. As someone with experience of installing and supporting multiple different MPI's on multiple different systems, it is thoroughly undesirable. Almost every compiler requires special flags to work together with MPI non-blocking transfers, those options are only sometimes documented and then typically in a place that only the most expert administrator will find (and no users that I have met). That is a BIG problem. 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