[PATCH] D27159: [ThreadPool] Simplify the interface

[Mehdi Amini via llvm-commits]

> On Nov 28, 2016, at 6:04 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
> 
> On Tue, Nov 29, 2016 at 10:18 AM, Mehdi AMINI via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
> mehdi_amini added a comment.
> 
> What is the motivation? This is removing a feature. Even though it is not used at that time, it is tested and could find its use in the future.
> 
> 
> https://reviews.llvm.org/D27159 <https://reviews.llvm.org/D27159>
> 
> 
> 
> 
> shared_future has a large performance overhead compared to just handing off a function pointer to another thread to run. 

That’s a good point, but “large overhead” is quite subjective. Note also that the LLVM ThreadPool has a global lock, so it is not intended for a lot of very small tasks (<100ms).
My first prototype was way more complex, and was wrapping around libdispatch when available or using C++11 construct otherwise. Much better for a lot of small tasks!
However the complexity was not worth it for my use case at the time: ThinLTO tasks range  between 100ms and a few seconds, so a few ms overhead don’t matter.

To focus on the submission part, I queued an empty task multiple times in a threapool with 0 threads, never deleted/synchronized, and measuring just the queuing time.

For 1000000 queuing, it went from 180ms to 500ms, which account on average to a queuing time for one task going from 180ns to 500ns, so the overhead of shared_future is 320ns per task.

As matter of comparison, to evaluate the overhead of the rest of the thread pool infrastructure, I reran the same experiment but this time with one thread in the pool processing these empty tasks. It took over 7s (so over 20 times the std::future overhead). Also, adding threads increases the contention and the performance drops (8.5s with 2 threads, and 11s with 4threads).

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161128/b025e2e4/attachment.html>