4 ms·

I really wonder what the C++ community will think of execution policies in 5 years. Using them seems to be interesting step up from coding your low level parall

I really wonder what the C++ community will think of execution policies in 5 years. Using them seems to be interesting step up from coding your low level parallel algorithms and instead using standard C++ algoritms with an execution policy to build your algorithm. But are they an abstraction that will be useful in the future? Worth it for the language?

Sharlin 8y ago
It's what others have been doing as well. For instance, Java Streams were written from the start with a fork/join execution model in mind, and in Rust rayon::par_iter() is often a drop-in replacement of the regular sequential iter().
ridiculous_fish 8y ago
I think execution policies will prove too abstract and coarse in their current state, so won't be very useful. Normally it's good to have pleasant abstractions and generic functions. But execution policies are there for speed and speed alone: if they don't make things faster, they've failed. So in this case it's worth tolerating a more awkward API to achieve better performance. The C++17 parallelism interface is more or less to declare "this loop can be parallelized," which does not provide enough information to the scheduler. You need to express properties of the algorithm, such as its optimal chunk size. (In the future perhaps those properties will enter into the execution policy as e.g. constructor parameters.) Second, passing in callbacks which receive one or two elements at a time is too granular. You are at the mercy of the compiler to optimize these. A better approach would be for the callbacks to receive a pair of iterators and allow the user to drive the loop. This makes it easier to avoid accidental indirections, failed alias analysis or inlining, etc. Intel's TBB will continue to be more useful here.
- AtlasBarfed 8y ago
  It does seem that custom policies are needed when deadlockable resource pools, throttling, or per-processor type of things need to be handled.
  - geezerjay 8y ago
    I don't believe these functions are supposed to be one-size-fits-all solutions. I assume they are intended as the answer to "how come std::transform() doesn't run this embarassingly parallel problem in parallel?"

Sharlin 8y ago

It's what others have been doing as well. For instance, Java Streams were written from the start with a fork/join execution model in mind, and in Rust rayon::par_iter() is often a drop-in replacement of the regular sequential iter().

ridiculous_fish 8y ago

I think execution policies will prove too abstract and coarse in their current state, so won't be very useful. Normally it's good to have pleasant abstractions and generic functions. But execution policies are there for speed and speed alone: if they don't make things faster, they've failed. So in this case it's worth tolerating a more awkward API to achieve better performance. The C++17 parallelism interface is more or less to declare "this loop can be parallelized," which does not provide enough information to the scheduler. You need to express properties of the algorithm, such as its optimal chunk size. (In the future perhaps those properties will enter into the execution policy as e.g. constructor parameters.) Second, passing in callbacks which receive one or two elements at a time is too granular. You are at the mercy of the compiler to optimize these. A better approach would be for the callbacks to receive a pair of iterators and allow the user to drive the loop. This makes it easier to avoid accidental indirections, failed alias analysis or inlining, etc. Intel's TBB will continue to be more useful here.

AtlasBarfed 8y ago
It does seem that custom policies are needed when deadlockable resource pools, throttling, or per-processor type of things need to be handled.
- geezerjay 8y ago
  I don't believe these functions are supposed to be one-size-fits-all solutions. I assume they are intended as the answer to "how come std::transform() doesn't run this embarassingly parallel problem in parallel?"