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

[Michael Spencer via cfe-dev]

On Tue, May 16, 2017 at 12:50 AM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi, Erik,
>
> That's great!
>
> Gor, Marshall, and I discussed this after some past committee meeting. We
> wanted to architect the implementation so that we could provide different
> underlying concurrency mechanisms; including:
>
>    a. A self-contained thread-pool-based implementation using a
> work-stealing scheme.
>
>    b. An implementation that wraps Grand Central Dispatch (for Mac and any
> other platforms providing libdispatch).
>
>    c. An implementation that uses OpenMP.
>
> The OpenMP-based provider is essential for interoperability in
> applications using OpenMP, GCD seemed most natural on Mac, and the
> self-contained implementation is available for anyone else. CUDA+UVM should
> be possible in the future as well. All of these mechanisms can export an
> interface for scheduling tasks, and we specifically discussed the interface
> having a "bulk enqueue" capability. This is essential for efficiently
> mapping onto several potential underlying technologies (e.g. OpenMP). You
> don't want to generate individual tasks for each item, and for underlying
> technologies that can do intelligent things, you want the underlying
> technology to make the coarsening decisions.
>
> par_unseq should map, via pragmas, either Clang-specific and/or OpenMP, to
> enabling vectorizaton. As a longer-term exercise, we might need additional
> compiler extensions to make this work well for some algorithms (such as
> sorting), dealing with exceptions, etc.
>
>  -Hal
>

Don't forget about ConcRT on Windows.

- Michael Spencer


> On 05/15/2017 11:54 AM, Erik Pilkington wrote:
>
> Hello all,
>
> I’m an intern at Apple this summer, and my project is to work on the C++17
> parallel algorithms library. In a recent thread, Hal mentioned [0] that he
> had spoken with Marshall about the design of the library. I’m currently
> working on a prototype that is pretty similar to what was committed into
> lib/Support in r302748. I’m wondering what you folks talked about, and if
> any consensus wrt to design has been reached. Even if not, I’d love to hear
> about what thoughts were exchanged, or any reference material that could
> bring me up to speed!
>
> It might also be worth having a conversation about how to divide up the
> work to be done here. Were any of you intending to start working on the
> library?
>
> Thanks!
> Erik
>
> [0] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112988.html
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170517/e65fdf26/attachment.html>