[PATCH] D32826: Move Parallel.h from LLD to LLVM

[Scott Smith via llvm-commits]

IMO the ThreadPoolExecutor from parallel.h is better than llvm::ThreadPool
for two reasons:
1. Thread spawning happens in another thread (for faster startup, as
indicated in the comment)
2. The work queue is a stack, not a queue, which IMO lends itself better to
recursive parallelism (i.e. work that spawns parallel work, etc).  Stack ==
depth first == bounded growth.

But that transformation should be separate from this change (either
llvm::ThreadPool->parallel's ThreadPoolExecutor or vice versa) and should
be debated in a separate review, since there are probably going to be more
opinions than actual choices ;-)

On Thu, May 4, 2017 at 2:53 PM, Zachary Turner <zturner at google.com> wrote:

> I interpreted the comment about using ThreadPool as replacing the
> homegrown task pool in Parallel.h, which is not used on the ConcRT path.  I
> agree that we cannot lose the ConcRT codepath.
>
> That said, I'm still not sure if I'm the right person to switch to make
> the switch over to ThreadPool.  I mean, I can try, but yea..  I'm not crazy
> about touching something this low-level that relates to multi-threaded code.
>
> On Thu, May 4, 2017 at 2:45 PM Michael Spencer <bigcheesegs at gmail.com>
> wrote:
>
>> On Thu, May 4, 2017 at 11:41 AM, Rui Ueyama via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> ruiu added a comment.
>>>
>>> If we are going to examine this file, I strongly recommend porting the
>>> same functionalities (i.e. parallel_for and parallel_for_each) on top of
>>> llvm/Support/ThreadPool.h. I don't think that is hard to do as TheadPool.h
>>> seems to provide the same functionality as this file. That would be easier
>>> than review this file again.
>>>
>>>
>>> https://reviews.llvm.org/D32826
>>>
>>>
>>>
>>>
>> My issue with just using Support/ThreadPool for everything is that
>> lld/Parallel.h uses ConcRT on Windows and is quite a bit faster than both
>> our implementations of thread pools. I don't want to punish Windows
>> performance. I'd also rather have our interface match whatever the standard
>> is doing in terms of parallel task execution.
>>
>> - Michael Spencer
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170504/6673aef6/attachment.html>