Re: [PATCH][gdbsupport] Use task size in parallel_for_each

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2022-07-22 15:08, Tom Tromey wrote:
> Pedro> My passerby comment is that I wonder whether we should consider
> Pedro> switching to a work stealing implementation, so that threads that
> Pedro> are done with their chunk would grab another chunk from the work
> Pedro> pool.  I think this would spare us from having to worry about
> Pedro> these distribution heuristics.
> 
> Tom> I also though about a dynamic solution, but decided to try the
> Tom> simplest solution first.
> 
> Tom> Anyway, with a dynamic solution you still might want to decide how big
> Tom> a chunck is, for which you could still need this type of heuristics.
> 
> I think the idea of the work-stealing approach is that each worker grabs
> work as it can, and so no sizing is needed at all.  If one worker ends
> up with a very large CU, it will simply end up working on fewer CUs.
> 
> In this situation, work stealing might make the overall implementation
> simpler.  Perhaps the batching parameter patch (commit 82d734f7a) and
> the vector of results patch (commit f4565e4c9) could be removed.
> 
> Then, rather than using parallel_for, the DWARF reader could send N jobs
> to the thread pool, and each job would simply take the next available CU
> by incrementing an atomic counter.  When the counter reached the number
> of CUs, a job would stop.
> 
> Tom

Just a nit, if we are talking about a centralized work pool that threads
pick from to get their next work item, that's not really work stealing.
Work stealing is when threads all have their own work queue, and threads
with empty queues go steal some work from other threads' queues.

I suppose a downside to having one centralized work item queue / pool
where threads pick one work item at a time is contention.  If you have a
ton of tiny work items, threads could spend a lot of time synchronizing
on that work queue, since they need to synchronize between each item.
With work stealing, there's no synchronization required until a thread
is actually out of work.

Given our work items are fairly large, I'm guessing that having one
centralized queue is fine.  Well, benchmarks will tell if that is faster
than Tom de Vries' balancing approach.

Simon