<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 05/12/2017 11:00 AM, Scott Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAHW2vrXfejCv=9vE4K9D9KKvXS3dSsdMo4NTRNKPWZSj2Fpa8A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
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.<br>
<br>
-Hal<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>