Take first task group for further execution

[zetanumbers]

Continuing from #153768 (comment).

I thought that storing a first group of tasks for immediate execution instead of pushing and immediately poping it from rayon's local task queue in par_slice would avoid overwhelming work stealing potentially blocking the original thread. So I've implemented this change.

8 threads benchmarks:

Benchmark	baseline~~9	new~take-first-group~1
	Time	Time	%
🟣 hyper:check	0.1110s	0.1086s	💚 -2.13%
🟣 hyper:check:initial	0.1314s	0.1298s	💚 -1.23%
🟣 hyper:check:unchanged	0.0771s	0.0755s	💚 -2.14%
🟣 clap:check	0.3787s	0.3757s	-0.80%
🟣 clap:check:initial	0.4680s	0.4564s	💚 -2.48%
🟣 clap:check:unchanged	0.2337s	0.2301s	💚 -1.52%
🟣 syn:check	0.4321s	0.4265s	💚 -1.31%
🟣 syn:check:initial	0.5586s	0.5401s	💚 -3.31%
🟣 syn:check:unchanged	0.3434s	0.3429s	-0.14%
🟣 regex:check	0.2755s	0.2661s	💚 -3.40%
🟣 regex:check:initial	0.3350s	0.3347s	-0.11%
🟣 regex:check:unchanged	0.1851s	0.1832s	💚 -1.01%
Total	3.5296s	3.4695s	💚 -1.70%
Summary	1.0000s	0.9837s	💚 -1.63%

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 11 candidates

[lqd]

I wonder what variance, and noise level, you're seeing on your benchmarking machine? BTZ, does this remove some small overhead a few times, or does it translate to good results on bigger benchmarks as well?

[jieyouxu]

@rustbot reroll

[zetanumbers]

I wonder what variance, and noise level, you're seeing on your benchmarking machine? BTZ, does this remove some small overhead a few times, or does it translate to good results on bigger benchmarks as well?

Here's baseline compiler running against itself:

Benchmark	baseline~~9	baseline~~9
	Time	Time	%
🟣 hyper:check	0.1143s	0.1157s	💔 1.25%
🟣 hyper:check:initial	0.1405s	0.1420s	💔 1.08%
🟣 hyper:check:unchanged	0.0805s	0.0797s	💚 -1.02%
🟣 clap:check	0.3914s	0.3909s	-0.14%
🟣 clap:check:initial	0.4765s	0.4823s	💔 1.21%
🟣 clap:check:unchanged	0.2345s	0.2329s	-0.68%
🟣 syn:check	0.4328s	0.4303s	-0.58%
🟣 syn:check:initial	0.5820s	0.5731s	💚 -1.53%
🟣 syn:check:unchanged	0.3695s	0.3696s	0.02%
🟣 regex:check	0.2668s	0.2720s	💔 1.95%
🟣 regex:check:initial	0.3224s	0.3289s	💔 2.02%
🟣 regex:check:unchanged	0.1901s	0.1846s	💚 -2.92%
Total	3.6015s	3.6021s	0.02%
Summary	1.0000s	1.0006s	0.06%

I have run these benchmarks on various changes before and never seen all greens like above.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Zoxc]

I wasn't able to reproduce the improvements. Perhaps different scheduling on Windows is the cause? The change seems unlikely to be a regression anyway.

Results with 7 threads:

Benchmark

Before

Before

After

Before

Before

After

Before

Before

After

Time

Time

%

Time

%

Physical Memory

Physical Memory

%

Physical Memory

%

Committed Memory

Committed Memory

%

Committed Memory

%

🟣 clap:check

0.3963s

0.3965s

0.04%

0.3979s

0.40%

204.25 MiB

204.22 MiB

-0.01%

204.14 MiB

-0.05%

276.78 MiB

276.56 MiB

-0.08%

276.79 MiB

0.00%

🟣 hyper:check

0.1318s

0.1308s

-0.80%

0.1309s

-0.69%

127.65 MiB

127.66 MiB

0.01%

127.60 MiB

-0.03%

195.84 MiB

195.82 MiB

-0.01%

195.83 MiB

-0.00%

🟣 regex:check

0.2722s

0.2726s

0.13%

0.2726s

0.15%

167.22 MiB

167.32 MiB

0.06%

167.29 MiB

0.04%

227.83 MiB

227.85 MiB

0.01%

227.92 MiB

0.04%

🟣 syn:check

0.5073s

0.5070s

-0.06%

0.5060s

-0.27%

197.98 MiB

198.04 MiB

0.03%

198.09 MiB

0.06%

259.91 MiB

260.00 MiB

0.03%

260.03 MiB

0.04%

Total

1.3077s

1.3068s

-0.07%

1.3074s

-0.02%

697.10 MiB

697.23 MiB

0.02%

697.12 MiB

0.00%

960.37 MiB

960.23 MiB

-0.01%

960.57 MiB

0.02%

Summary

1.0000s

0.9983s

-0.17%

0.9990s

-0.10%

1 byte

1.00 bytes

0.02%

1.00 bytes

0.00%

1 byte

1.00 bytes

-0.01%

1.00 bytes

0.02%

[Zoxc]

I did a benchmark run with 7 threads in a Linux VM and that does look like an improvement:

Benchmark	Before	Before		After
	Time	Time	%	Time	%
🟣 regex:check	0.2905s	0.2895s	-0.33%	0.2877s	-0.95%
🟣 hyper:check	0.1317s	0.1307s	-0.76%	0.1295s	💚 -1.71%
🟣 clap:check	0.4345s	0.4347s	0.06%	0.4299s	💚 -1.05%
🟣 syn:check	0.5256s	0.5248s	-0.15%	0.5209s	-0.90%
Total	1.3823s	1.3798s	-0.18%	1.3680s	💚 -1.03%
Summary	1.0000s	0.9970s	-0.30%	0.9885s	💚 -1.15%

[nnethercote]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 7162208 (7162208e3ee809a53abb3682431abfd4dd7bf537, parent: cf7da0b7277cad05b79f91b60c290aa08a17a6f0)

[rust-timer]

Finished benchmarking commit (7162208): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.1%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.4%	[1.6%, 3.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[1.6%, 3.1%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 483.836s -> 484.409s (0.12%)
Artifact size: 394.90 MiB -> 394.83 MiB (-0.02%)