[llvm-dev] PSA: Parallel STL algorithms available in LLVM

[Hal Finkel via llvm-dev]

On 05/12/2017 11:00 AM, Scott Smith wrote:
> On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach <balelbach at lbl.gov 
> <mailto:balelbach at lbl.gov>> wrote:
>
>     * I am concerned that nested parallel algorithms will prove to be a
>     big implementation burden for GPU and accelerator architectures.
>
>
> Can't they fall back on serial execution?  I thought the executor is a 
> hint, not a requirement (certainly the standard doesn't say it has to 
> execute on multiple threads, just that it may).
>
>
>     However, I want to gently urge caution and then take this thread on a
>     bit of a tangent, because I suspect this work will start leading
>     towards whatever goes into the libc++ C++17 parallel algorithms
>     implementation. Even if the intention is to have a separate,
>     stand-alone implementation in LLVM Support, I think that
>     implementation should share some interfaces and design philosophy with
>     whatever goes into libc++. I think there is a very important step that
>     needs to be taken before substantial work is done on libc++'s parallel
>     algorithms.
>
>
> I fear what you're describing is another 1.5 year long standards 
> committee-like process, involving multiple stakeholders, discussions, etc.
>
> The background of how this came to be in LLVM is roughly:
> 1. I wanted to parallelize more work in LLDB, which has it's own 
> non-nestable task execution model.  It involved creating individual 
> tasks, rather than describing the iteration requested, so I put 
> together my own parallel:for_each-like implementation just for LLDB.
> 2. It was suggested that rather than have each LLVM subproject 
> implement its own framework, that it should instead be put into LLVM 
> proper.  Zachary volunteered to do that, taking code from LLD and 
> pulling it into LLVM.
> 3. It was then suggested that the interface should look more like the 
> C++17 standard, presumably to make it easier to transition to the 
> standard library and drop LLVM's own implementation once the time was 
> right.
> 4. Back to LLDB, I want to make more code use for_each, but that code 
> may itself call for_each, so in order to avoid creating Yet Another 
> parallelism model, I want to make sure LLVM's for_each supports nested 
> calling.
>
> As it is, we have a real use case today for this behavior, but not the 
> resources/time to invest in coming up with defining how a shared 
> library interface should look, separate from the C++17 parallelism 
> interface, just so that libc++ may (or may not) pick it up somewhere 
> down the line.
>
> IMO it makes more sense to continue with the separate implementation 
> of "kinda mostly C++17 parallelism" with minimal changes/improvements 
> as necessary inside LLVM, and then switch to libc++/libstdc++/etc 
> standard implementation later once those interfaces are implemented 
> and pervasive across all the architectures that LLVM needs to work 
> on.  Otherwise, we hold up progress in LLVM/LLDB today.

I agree. I've chatted a couple of times with Marshall about the design 
for parallel algorithms in libc++. I think that we have a reasonable 
idea of what we'd like to do there, at least in some general sense. I'd 
not hold up this work on a libc++-appropriate implementation. Having the 
use case, however, is definitely valuable.

  -Hal

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170512/b4be6a01/attachment.html>