Even without a concrete use case, I agree that it's absolutely imperative for the standard to require this of a conforming implementation.  It's going to be the source of so many problems otherwise <br><div class="gmail_quote"><div dir="ltr">On Fri, May 12, 2017 at 9:14 AM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="m_821367662045903986moz-cite-prefix">On 05/12/2017 11:00 AM, Scott Smith
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div><div bgcolor="#FFFFFF" text="#000000">
    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.</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <br>
     -Hal</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <pre class="m_821367662045903986moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </div></blockquote></div>