Draft: Add threadpool mappers for scheduler_reweight

Is better than serial code (100ms compared to 500ms in my test), but has one issue, which is some weights will be less optimal than before as the accumulation of weights will not happen between threads. This is why we use a uniform chunk to keep the work load from too many splits. For any reasonable set of tasks this is a small issue, there is no effect measureable that I can see.

added enhancement performance labels

assigned to @pdraper

@matthieu seems a sensible change to me. As I said there is an issue, but given weighting is an inexact science anyway, not really much of an actual concern. Look OK to you?

I don't recall exactly why this wasn't done in the past. Was it because we were accumulating weights using a different formula which was preventing parallelism?

Sort of, the construction was running over all tasks in reverse ranked order so that the weights could be accumulated in that direction (since unlocks are seen before the tasks without locks, so their weights are available to add in). So one loop to construct the individual weights was always possible using a threadpool mapper, but a second full loop would be needed to run over all the tasks once more to accumulate weights in that order (I believe). So that takes into account multiple unlocks (i.e. ordered by number of waits).

The second mapper breaks this a bit, that is runs of dependent tasks that are in more than one threadpool chunk will miss some weight. So we keep the number of chunks, hence breaks in the runs, to a minimum.

Does that mean we forego the idea of running the longest possible chain first?

added 1 commit

• f833cb64 - Don't split the accumulation pass using the threadpool, turns out to be a bad...

Compare with previous version

added 10 commits

• f833cb64...c2b024a3 - 9 commits from branch master
• 3d4db2f1 - Merge remote-tracking branch 'origin/master' into threadpool-reweight-mappers

Compare with previous version

Turns out that the answer is a firm yes, all the longer chains are reduced in weight by some order of magnitudes. Given that I've reverted to a single loop that accumulates weights and checked this is the same as before. Still somewhat faster to use the threadpool (x2 not x5) for the initial weights pass. All on COSMA8 with interleaving so no comment on other NUMA machines, but I doubt it could be much worse!

assigned to @matthieu and unassigned @pdraper

Do you understand why this version with threadpool + scalar loop is faster than the old version? Seems like we now have to pass twice over the tasks. That somehow feels like it should be slower.

added 156 commits

• 3d4db2f1...1698369a - 155 commits from branch master
• 5fd6d0f9 - Merge branch 'master' into threadpool-reweight-mappers

Compare with previous version