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

[C Bergström via cfe-dev]

On Tue, May 16, 2017 at 2:50 PM, 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.
>

Sorry to butt in, but I'm kinda curious how these will be substantially
different under the hood

"OpenMP" is a pretty vague term and I'm curious what that means in terms of
actual directives used. All non-accelerator OpenMP implementations lower
down to threading currently. (Even if you use tasks it still ends up being
a thread)

GCD (libdispatch) is essentially a task based execution model, but again on
non-OSX platforms lowers to threads. (I have a doubt that GCD offers any
performance benefit over native threads or Intel OMP runtime on OSX.)

How would the above offer any benefit over a native thread pool? Would you
be just duplicating code which is already working?
--------------
I'm no OMP advocate, but I'd find it significantly more sane to target the
Intel OMP runtime API directly.
* Production ready
* Portable across CPU (Intel, ARM, Power8)
* Likely provides the interface needed for parallelism
* Single approach
* Already part of the llvm infrastructure without external dependencies.

I don't know how well the API will map to accelerators, but for something
quick and easy it's likely to the easiest.

Bryce I think even mentioned he had used it before with positive results?

In contrast the other approaches will loosely couple things to external
dependencies and be more difficult to debug and support long term. It will
introduce additional build dependencies which will likely add barriers to
others contributing.

I'm not writing the code and just trying to offer another pragmatic point
of view..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170516/e0f24d4f/attachment.html>