From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 16 10:01:22 2015 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id A8E3D3582A9; Wed, 16 Sep 2015 10:01:22 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 2B95D35664D for ; Wed, 16 Sep 2015 10:01:17 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39915) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:nmm1) id 1Zc7eV-0001Qy-XO (Exim 4.86_36-e07b163) (return-path ); Wed, 16 Sep 2015 09:01:15 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1Zc7eV-0008WE-9U (Exim 4.72) (return-path ); Wed, 16 Sep 2015 09:01:15 +0100 Received: from [87.114.7.134] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 16 Sep 2015 09:01:15 +0100 Date: 16 Sep 2015 09:01:15 +0100 From: "N.M. Maclaren" To: Van.Snyder@jpl.nasa.gov Cc: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.5562) (j3.2006) LCPC conference in Raleigh Message-ID: In-Reply-To: <20150915204333.E678F358262@www.open-std.org> References: <20150915023108.BA4D6357225@www.open-std.org> <0B2E6F4E-134C-4142-B0BC-3EFE6BCA0458@cray.com> <20150915204333.E678F358262@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-sc22wg5@open-std.org Precedence: bulk On Sep 15 2015, Van Snyder wrote: >On Tue, 2015-09-15 at 13:37 +0000, Bill Long wrote: > >> > Many speakers remarked that >> > multigrain parallelism gives greater speed-up. Some speakers >> mentioned >> > fork-join constructs. Others mentioned tasks and threads (I don't >> know >> > what distinctions they drew between these). Somebody mentioned >> futures. >>=20 >> My experience is biased by SLURM, but I usually assume task -> image, >> and thread -> SMP thread within an image to support local parallelism >> (OpenMP, DO CONCURRENT, Async I/O, =E2=80=A6).=20 > >Ada tasks don't fit the image model well. Maybe they're closer to >threads. No, they aren't. No form of tasks is. Part of the trouble is that the terms have been grossly abused as well as being used to fit different concepts (e.g. a Unix 'job' is a background process, and not a job). Tasks have (almost always) been a partially or wholly isolated transactions= =20 or 'procedure calls' (though sometimes with a non-procedure interface), NOT= =20 always asynchronous. Futures predate X10 by a long way and are simply=20 asynchronous transactions, usually mapped as procedure calls. Fortran could= =20 add futures extemely easily, but could NOT integrate them with coarrays -= =20 the image concept is seriously incompatible. Future iterators are trickier,= =20 because the cover a multititude of sins, but not all that hard. You may=20 recall me raising the possibility of futures :-) MPI_SEND_INIT has nothing to do with transactions, and is merely a way of setting up semi-permanent communication channels. It's a red herring. Regards, Nick.