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

Subject: Re: [boost] We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-10-12 22:02:52

Le 12/10/15 14:52, Hartmut Kaiser a écrit :
> 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.
Hi Hartmut,

I can agree with you at the C++ standard level, but I have a library to 
maintain, and I have introduced a very BIG BUG making all the futures 
block on destruction (develop branch). Now, there is a major need to 
make the futures returned by then() to be non-blocking. The branch 
non_blocking_futures has the opposite. However, there are people that 
would like that the boost::async follows the standard. So, I don't know 
what to do, fix future::then() and break async(), or deliver the fiw 
only when async will conform to the standard; knowing that this behavior 
might be deprecated in 2017.
I need the feedback from the Boost community respect to this point.
>
> 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]).
I'm aware of most of them if not all. I've been implementing/introducing 
some of these facilities in Boost.Thread recently. I have not 
implemented the parallel algorithms yet, as this will require time I 
don't have now.
I'm aware of these proposals, and as others I'm experimenting as we 
don't know yet what would be the final interface.
> We have a (strong) proposal for simplifying continuation based programming
> (await, PR0057R0 [8]).
>
> We have attempts on integrating executors with existing facilities (Boost,
> HPX).
A pointer?
> 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.
I plan to update the N4414 Executors and Schedulers Revision 5 proposal 
as I believe that Executors must be copyable and lightweight.
The new proposal P0008R0 comes back to executors that are not copyable 
and so left the responsibility of the the lifetime  to the user (I'm 
experimenting it in branch make_executors_copyable)
> 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.
I'll read it and come back to you.

Best,
Vicente
>
>
> 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
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>