From owner-sc22wg5@open-std.org Wed Jan 21 23:27:20 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 C8C68CA3434; Wed, 21 Jan 2009 23:27:20 +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 38F92C178D9 for ; Wed, 21 Jan 2009 23:27:18 +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 n0LMR8In028523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jan 2009 16:27:08 -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 n0LMR5kC022729; Wed, 21 Jan 2009 16:27:05 -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:27:05 -0600 Message-ID: <4977A1E7.50407@cray.com> Date: Wed, 21 Jan 2009 16:29:59 -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> <200901211012.44002.donev1@llnl.gov> <49776DF7.1040900@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:27:05.0273 (UTC) FILETIME=[63882A90:01C97C17] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > > > 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. More precisely, no proposals since you have joined the discussion. There have been proposals in the past that would create a "real" Fortran interface for MPI that was completely different from the C interface. It would use assumed-shape dummies. (Solves the copy-in/copy-out problem.) With the associated descriptors, a large number of the arguments to MPI routines could be dropped. (Improves on the difficulty of use problem and reduces coding mistakes.) > > > 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. > I agree that there are problems with the current arrangement. I just was pointing out that these problems have been solved in some way or another (perhaps not elegantly). MPI *does* work. Every day in real production. It it didn't, there would be no motivation to continue improving it. 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