[cfe-dev] [libc++] Working on the parallel STL algorithms

[Bryce Lelbach via cfe-dev]

On Wed, May 17, 2017 at 9:13 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> I don't see why you have that concern. We have plenty of existing parallel
> abstraction libraries (e.g. Kokkos) that have multiple backends, including
> OpenMP, and don't have this problem. You can certainly have a set of
> templates that implement bulk task dispatch, etc. in terms of OpenMP and a
> set of templates that implement that interface in terms of other things. The
> key thing here is to reuse the thread pool and get the added compiler
> optimizations that the pragmas can imply (when OpenMP is available).

Upon reflection, I think you're correct. I probably let some of my
prior experience with OMP (pragmas sprinkled all over the place in
applications, historical avoidance of nested OMP and composition, and
some of the rough edges that you get when using OMP on iterator loops
with certain compilers) bias my thinking a bit. With the right
approach, like the design you suggested, makes sense to me, and as you
mentioned there's plenty of prior art.

You make an excellent point about leveraging existing OpenMP compiler
optimizations (this is actually one of the reasons that we wrote an
OpenMP compatibility layer for HPX!).

> To be clear, I'm not proposing that we put OpenMP pragmas on the algorithm
> implementations themselves, only use it for an underlying
> parallelism-execution provider.

+1 - I think my concern was mostly to make sure we do this.

> What is true, AFAIK, is that the abstractions don't play well with OpenMP
> pragmas that take variable names (reductions, for example) in a general way.
> Thus, for example, it is not straightforward/possible to have a variadic
> template that takes a list of variables on which to perform a reduction and
> transform that into a loop with a pragma with the right list of variables in
> a reduction clause (in general). You can handle specific cases (e.g. one
> reduction variable for specific operations).

I think this is the only case we have in the current algorithms.

> I don't even know that we run into this problem with the current set of standardized algorithms.

Yep, I believe this is correct.



-- 
Bryce Adelstein Lelbach aka wash
Lawrence Berkeley National Laboratory
ISO C++ Committee Member
CppCon and C++Now Program Chair

Compiler ICE Hunter
--