[Lldb-commits] [PATCH] D32757: Add TaskMap for iterating a function over a set of integers

[Zachary Turner via lldb-commits]

Then make it ready :-/

Why does LLDB need llvm::ThreadPool for this to work?  I proposed a single
function that is not dependent on any particular instance of a thread pool.


template<typename Range, typename Func>
void parallel_for_each(Range &&R, Func &&F) {
  // call F(Index, *Iter) for every item in R.
}

std::vector<std::string> Foos = { "a", "b", "c" };

void handle_foo(int N, const std::string &S) {}

llvm::parallel_for_each(Foos, handle_foo);

There's nothing that needs to be done here to make this ready for
llvm::ThreadPool, because all you have to do is use it.

Perhaps the function could create a llvm::ThreadPool on the stack to be
used for this one operation.

Perhaps llvm is willing to allow a single global thread pool to be created
for parallel operations, and entire library of parallel functions could be
added that use the same global thread pool.

Or maybe we could have llvm::initializeParallelThreadPool(unsigned
Concurrency) that specifies the number of threads to create and all
operations will use that global thread pool.

The point is, without even making an effort to try, we don't know what
issues will people will have or how hard it even is.  It might end up being
trivial, and you would get a lot of valuable performance and safety
feedback from some very good experts on the subject.

I'm not stating an ultimatum that the only way this will go in is if it's
in LLVM, but I *am* stating that LLVM needs to be the starting point for
discussion here, and only after we discover (if we discover) that a
solution cannot work, we can revisit this in LLDB.

This is useful functionality that could be used everywhere, and I would
like to see due diligence done here.

On Tue, May 2, 2017 at 1:56 PM Scott Smith via Phabricator <
reviews at reviews.llvm.org> wrote:

> scott.smith added a comment.
>
> In https://reviews.llvm.org/D32757#743796, @zturner wrote:
>
> > s/instead of LLVM/instead of LLDB/
>
>
> I hear you, but IMO it's not ready for that yet.
>
> 1. It would depend on ThreadPool, but
> 2. LLDB hasn't switched to ThreadPool yet, because
> 3. I want to figure out how to incorporate tasks enqueuing tasks first.
>
> I don't want to commit a monolithic patch with all my changes (and I
> haven't developed them all yet), so instead I submit incremental
> improvements.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D32757
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170502/7b959f94/attachment.html>