(j3.2006) (SC22WG5.5565) [ukfortran] LCPC conference in Raleigh

[Bill Long]

On Sep 16, 2015, at 3:01 AM, N.M. Maclaren <nmm1 at cam.ac.uk> wrote:

> 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.
>>> 
>>> 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, ?). 
>> 
>> 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 
> or 'procedure calls' (though sometimes with a non-procedure interface), NOT 
> always asynchronous.

Interesting.  I?ve seen ?task? used for many things, but never that.  Probably a good idea to just banish the word from computing.   The problem is that batch systems have various terminology (node, task, thread, cpu, process, ?) that have no connection to the programmer?s perspective (image, async execution within the image from DO CONCURRENT and Async I/O).   Getting rid of the batch system  (generally a good idea in my experience) does not solve the problem  - it just moves to the command used to launch the program. 


> Futures predate X10 by a long way and are simply 
> asynchronous transactions, usually mapped as procedure calls. Fortran could 
> add futures extemely easily, but could NOT integrate them with coarrays - 
> the image concept is seriously incompatible.

Also interesting, since that is basically how coarray data transfers are handled in the runtime library for target architectures without global addressing.  You initiate the transfer as an async transaction, and then (possibly much later) check the completion queue entry for that transaction before executing a statement that assumes the transfer had completed. 

This does not seem that different from the ?sync? attribute for variables in the MTA variant of C.  Such variables have a state (simplified version) of either full or empty that is enforced by the memory system.  If you try to reference a variable with a memory location with a state of empty, your thread stalls until some other thread defines (fills) the memory location.  It?s an efficient fine-grain thread synchronization scheme when you have hundreds or thousands of threads, assuming you have hardware support in the memory system.  Even I would agree that this qualifies as what Nick likes to call ?specialist hardware?. 

Cheers,
Bill


> Future iterators are trickier, 
> because the cover a multititude of sins, but not all that hard. You may 
> 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.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101