<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 2:50 PM, Hal Finkel via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Hi, Erik,</p>
    <p>That's great!<br>
    </p>
    <p>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:</p>
    <p>   a. A self-contained thread-pool-based implementation using a
      work-stealing scheme.</p>
    <p>   b. An implementation that wraps Grand Central Dispatch (for
      Mac and any other platforms providing libdispatch).</p>
    <p>   c. An implementation that uses OpenMP.</p></div></blockquote><div><br></div><div>Sorry to butt in, but I'm kinda curious how these will be substantially different under the hood<br><br></div><div>"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)<br><br></div><div>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.)<br><br></div><div>How would the above offer any benefit over a native thread pool? Would you be just duplicating code which is already working?<br>--------------<br></div><div>I'm no OMP advocate, but I'd find it significantly more sane to target the Intel OMP runtime API directly.<br></div><div>* Production ready<br></div><div>* Portable across CPU (Intel, ARM, Power8)<br></div><div>* Likely provides the interface needed for parallelism<br></div><div>* Single approach<br></div><div>* Already part of the llvm infrastructure without external dependencies.<br></div><div><br></div><div>I don't know how well the API will map to accelerators, but for something quick and easy it's likely to the easiest.<br><br></div><div>Bryce I think even mentioned he had used it before with positive results?<br><br></div><div>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.<br><br></div><div>I'm not writing the code and just trying to offer another pragmatic point of view..<br><br></div></div></div></div>