[boost] We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)

Subject: [boost] We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-10-12 08:52:42

Sorry for cross-posting.

> Vicente J. Botet Escriba wrote:
> 
> I have a branch
> (https://github.com/boostorg/thread/tree/feature/non_blocking_futures)
> that don't blocks on any future, but this will break async.

FWIW, the design decision to let those (and only those) futures block on
destruction which are returned from async was one of the really bad
decisions made for C++11, however that's just my opinion (others agree, but
yet others disagree). This flaw essentially caused us to spend many
committee hours on discussions how to mitigate the situation, with proposed
solutions ranging from 'leave it be as is' to as extreme as 'deprecate it
now'. There seems to be a growing consensus however to develop other
constructs which eventually could replace async, such as executors, etc. I'm
a proponent of following that path. 

More generally, I strongly believe that we have to come up with a _coherent
story_ for all kinds of (higher-level) parallelism in C++: task-based
parallelism, asynchronous, continuation style programming, fork-join
parallelism of heterogeneous tasks, simple fork-join (iteration based)
parallelism, etc. All of this has to go hand in hand with a (orthogonal)
vectorization story. We also need to think about integrating GPUs.

The goal has to be to make parallelism in C++ independent of any external
solutions such as OpenMP, OpenACC, etc.

Many of the building blocks for this are already being discussed: executors
and executor_traits for customizing the 'how and where' of task execution,
executor parameters for grain-size control, and execution policies as the
higher level facility allowing to tie everything together (see for instance
HPX [7]). 

We (as a committee) already allow for passing execution policies as the
first argument to parallel algorithms (Parallelism TS, N4505 [2]).
We already have some facilities for task-based, asynchronous, and
continuation style parallelism in place (Concurrency TS, N4501 [3]).

We have a paper proposing task_blocks for fork-join parallelism of
heterogeneous tasks (N4411 [4]).
We have two competing (but converging) efforts for defining an executor
concept (N4406 [5], PR0008R0 [6]).
We have a (strong) proposal for simplifying continuation based programming
(await, PR0057R0 [8]).

We have attempts on integrating executors with existing facilities (Boost,
HPX).

We miss work on parallel ranges.
We miss work on integrating data structures with data placement policies in
conjunction with executors.
We miss work on extending all of this to many-core, distributed, and
high-performance computing.

Etc.

We (as a community) really need a higher level, over-arching approach which
ties all of the above together! My plan is to work on a corresponding
concept paper by the time of the committee meeting end of February 2016. Our
group has outlined our current understanding and a possible approach to this
here [1]. I'd like for this to be understood as a seed for a wider
discussion. Needless to say, I'd very much like to collaborate on this with
anybody interested in joining the effort.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

[1] http://stellar.cct.lsu.edu/pubs/executors_espm2_2015.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4505.pdf
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf
[6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf
[7] http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel.html
[8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.pdf