llvm dev - May 2017 - PSA: Parallel STL algorithms available in LLVM

It's hard to say.  By definition it appears undefined (in the sense that
the TS literally does not define it), but on the other hand it is a TS and
this issue would (hopefully) come up and be specified before it made it to
standardization.

Supporting recursive parallel calls certainly seems like desirable
behavior, so from my point of view it would be nice to make sure it works.
Not sure if others feel differently.

On Wed, May 10, 2017 at 8:08 PM Scott Smith <scott.smith at
purestorage.com>
wrote:
> The spec doesn't seem to say anything about recursive calls to parallel
> functions.  In my mind that means the functions must support it, since it
> doesn't explicitly say it does not need to support it.  Do you think
that's
> accurate?
>
> If so, I'll rely on that behavior in LLDB, and extend the
implementation
> in LLVM accordingly.
>
> On Wed, May 10, 2017 at 5:37 PM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> This is just a PSA that as of r302752, 3 parallel algorithms (for_each,
>> for_each_n, and sort) are available in llvm/Support/Parallel.h.
>>
>> Effort was made to match the C++ Parallelism TS N4507 [
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf] as
>> closely as possible, but some aspects were intentionally omitted.
>>
>> No support is added for the executor proposal N4406 [
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf], but
>> I plan to try to work on this in the future, with no specified
timeline.
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/15ea8cbb/attachment.html>

It seems to me like this would be the responsibility of the executor being
used.  You might have one parallel executor which uses a fixed size thread
pool, and another which can dynamically add more threads if they are
needed.  In any case, I would still hope that it be specified by the time
of standardization.  Since the current executor stuff is all magically
hidden away and inaccessible, I guess it wouldn't hurt to add this logic
there?

On Wed, May 10, 2017 at 8:36 PM Zachary Turner <zturner at google.com>
wrote:
> It's hard to say.  By definition it appears undefined (in the sense
that
> the TS literally does not define it), but on the other hand it is a TS and
> this issue would (hopefully) come up and be specified before it made it to
> standardization.
>
> Supporting recursive parallel calls certainly seems like desirable
> behavior, so from my point of view it would be nice to make sure it works.
> Not sure if others feel differently.
>
> On Wed, May 10, 2017 at 8:08 PM Scott Smith <scott.smith at
purestorage.com>
> wrote:
>
>> The spec doesn't seem to say anything about recursive calls to
parallel
>> functions.  In my mind that means the functions must support it, since
it
>> doesn't explicitly say it does not need to support it.  Do you
think that's
>> accurate?
>>
>> If so, I'll rely on that behavior in LLDB, and extend the
implementation
>> in LLVM accordingly.
>>
>> On Wed, May 10, 2017 at 5:37 PM, Zachary Turner via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> This is just a PSA that as of r302752, 3 parallel algorithms
(for_each,
>>> for_each_n, and sort) are available in llvm/Support/Parallel.h.
>>>
>>> Effort was made to match the C++ Parallelism TS N4507 [
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf]
as
>>> closely as possible, but some aspects were intentionally omitted.
>>>
>>> No support is added for the executor proposal N4406 [
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf],
but
>>> I plan to try to work on this in the future, with no specified
timeline.
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/d1af0798/attachment.html>

On 05/10/2017 10:36 PM, Zachary Turner via llvm-dev
wrote:
> It's hard to say.  By definition it appears undefined (in the sense 
> that the TS literally does not define it), but on the other hand it is 
> a TS and this issue would (hopefully) come up and be specified before 
> it made it to standardization.
You mean the parallelism TS that was voted into C++17? ;)

Bryce, did they end up defining this?

  -Hal
>
> Supporting recursive parallel calls certainly seems like desirable 
> behavior, so from my point of view it would be nice to make sure it 
> works.  Not sure if others feel differently.
>
> On Wed, May 10, 2017 at 8:08 PM Scott Smith 
> <scott.smith at purestorage.com <mailto:scott.smith at
purestorage.com>> wrote:
>
>     The spec doesn't seem to say anything about recursive calls to
>     parallel functions.  In my mind that means the functions must
>     support it, since it doesn't explicitly say it does not need to
>     support it.  Do you think that's accurate?
>
>     If so, I'll rely on that behavior in LLDB, and extend the
>     implementation in LLVM accordingly.
>
>     On Wed, May 10, 2017 at 5:37 PM, Zachary Turner via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>         Hi all,
>
>         This is just a PSA that as of r302752, 3 parallel algorithms
>         (for_each, for_each_n, and sort) are available in
>         llvm/Support/Parallel.h.
>
>         Effort was made to match the C++ Parallelism TS N4507
>         [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf]
>         as closely as possible, but some aspects were intentionally
>         omitted.
>
>         No support is added for the executor proposal N4406
>        
[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf],
>         but I plan to try to work on this in the future, with no
>         specified timeline.
>
>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/c567760c/attachment.html>

On May 10, 2017 9:14 PM, "Hal Finkel" <hfinkel at anl.gov>
wrote:

On 05/10/2017 10:36 PM, Zachary Turner via llvm-dev wrote:

It's hard to say.  By definition it appears undefined (in the sense that
the TS literally does not define it), but on the other hand it is a TS and
this issue would (hopefully) come up and be specified before it made it to
standardization.


You mean the parallelism TS that was voted into C++17? ;)

Bryce, did they end up defining this?


TL;DR: ... $*!#

I'll take a full look at this tomorrow


 -Hal


Supporting recursive parallel calls certainly seems like desirable
behavior, so from my point of view it would be nice to make sure it works.
Not sure if others feel differently.

On Wed, May 10, 2017 at 8:08 PM Scott Smith <scott.smith at
purestorage.com>
wrote:
> The spec doesn't seem to say anything about recursive calls to parallel
> functions.  In my mind that means the functions must support it, since it
> doesn't explicitly say it does not need to support it.  Do you think
that's
> accurate?
>
> If so, I'll rely on that behavior in LLDB, and extend the
implementation
> in LLVM accordingly.
>
> On Wed, May 10, 2017 at 5:37 PM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> This is just a PSA that as of r302752, 3 parallel algorithms (for_each,
>> for_each_n, and sort) are available in llvm/Support/Parallel.h.
>>
>> Effort was made to match the C++ Parallelism TS N4507 [
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf] as
>> closely as possible, but some aspects were intentionally omitted.
>>
>> No support is added for the executor proposal N4406 [
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf], but
>> I plan to try to work on this in the future, with no specified
timeline.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/6a2a13e5/attachment.html>