<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 05/12/2017 11:19 AM, Zachary Turner
wrote:<br>
</div>
<blockquote
cite="mid:CAAErz9ihjBs05OXx+sMbZ=OC5Y1KmiN--a_CdnFmZyyZEnEEtA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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>
</blockquote>
<br>
I agree that it should work in some sense, but I meant that having
the use case against which we can evaluate different implementation
strategies is important.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAAErz9ihjBs05OXx+sMbZ=OC5Y1KmiN--a_CdnFmZyyZEnEEtA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div dir="ltr">On Fri, May 12, 2017 at 9:14 AM Hal Finkel <<a
moz-do-not-send="true" 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
moz-do-not-send="true"
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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>