From 520e171371e3facc1ade7ad25d98d62c4eebebad Mon Sep 17 00:00:00 2001 From: Josh Stone Date: Thu, 13 May 2021 11:06:38 -0700 Subject: [PATCH] Simplify the iterator adaptive splitting strategy Before, when an iterator job was stolen, we would reset the split count all the way back to `current_num_threads` to adaptively split jobs more aggressively when threads seem to need more work. This ends up splitting a lot farther than a lot of people expect, especially in the tail end of a computation when threads are fighting over what's left. Excess splitting can also be harmful for things like `fold` or `map_with` that want to share state as much as possible. We can get a much lazier "adaptive" effect by just not updating the split count when we split a stolen job, effectively giving it only _one_ extra boost of splitting. --- src/iter/plumbing/mod.rs | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/iter/plumbing/mod.rs b/src/iter/plumbing/mod.rs index 71d4fb4c3..565bd179c 100644 --- a/src/iter/plumbing/mod.rs +++ b/src/iter/plumbing/mod.rs @@ -273,9 +273,8 @@ impl Splitter { let Splitter { splits } = *self; if stolen { - // This job was stolen! Reset the number of desired splits to the - // thread count, if that's more than we had remaining anyway. - self.splits = cmp::max(crate::current_num_threads(), self.splits / 2); + // This job was stolen! Leave the `splits` count alone while we go ahead and split + // anyway, so we dynamically get more splitting for jobs that are moving a lot. true } else if splits > 0 { // We have splits remaining, make it so.