(j3.2006) (SC22WG5.5562) LCPC conference in Raleigh

[Van Snyder]

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.  "Concurrent and Real-Time Programming in Ada" by Burns and
Wellings describe yet another construct, which I think arrived in Ada
95, that seems more like a persistent task that can be reactivated where
it suspended, instead of being destroyed and recreated.  More like a
coroutine than a subroutine.

Univac 1100 Exec had (at least) five API's for parallelism: Fork, Exit,
Activate, Deactivate, and Wait.  Fork created what we would today call a
thread.  Exit destroyed it.  Deactivate put a thread to sleep without
destroying it.  Activate restarted a sleeping thread.  Wait waited for a
thread to deactivate or exit.  There was also a Name API that would get
a thread's name so that another thread could wait for it or activate it.
Between, Fortran can do DACT with an event wait, and ACT with an event
post.  To address unstructured problems (graph, mesh, sparse matrix),
where parallelism opportunities depend more upon the data presented than
upon the properties of the algorithm, we need two more parallelism
constructs between DO CONCURRENT and coarray images: a fork-join
construct, which one can fake with a SELECT CASE inside DO CONCURRENT,
and either a "spawn" construct or a task unit a la ada.

One of the presenters (it might have been Hadia Ahmed) described
persistent MPI transactions.  Does anybody's coarray implementation use
this (or its equivalent in a different transport mechanism)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150915/3bdd057d/attachment.html