<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach <span dir="ltr"><<a href="mailto:balelbach@lbl.gov" target="_blank">balelbach@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* I am concerned that nested parallel algorithms will prove to be a<br>
big implementation burden for GPU and accelerator architectures.<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
However, I want to gently urge caution and then take this thread on a<br>
bit of a tangent, because I suspect this work will start leading<br>
towards whatever goes into the libc++ C++17 parallel algorithms<br>
implementation. Even if the intention is to have a separate,<br>
stand-alone implementation in LLVM Support, I think that<br>
implementation should share some interfaces and design philosophy with<br>
whatever goes into libc++. I think there is a very important step that<br>
needs to be taken before substantial work is done on libc++'s parallel<br>
algorithms.<br></blockquote><div><br></div><div>I fear what you're describing is another 1.5 year long standards committee-like process, involving multiple stakeholders, discussions, etc.<br><br></div><div>The background of how this came to be in LLVM is roughly:<br></div><div>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.<br></div><div>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.<br></div><div>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.<br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div></div></div></div>