Remove the use of Rayon iterators

[Zoxc]

This removes the use of Rayon iterators and the use of the rustc-rayon crate. rustc-rayon-core is still used however.

In parallel loops, instead of a Rayon iterator a serial iterator are used to collect items into a Vec and we use a parallel loop over its elements using the new par_slice function which is built on rustc-rayon-core's join.

This change makes it easier to bring rustc-rayon-core in-tree.

Tests using 7 threads:

Benchmark	Before	After		Before	After		Before	After
	Time	Time	%	Physical Memory	Physical Memory	%	Committed Memory	Committed Memory	%
🟣 clap:check	0.4827s	0.4828s	0.02%	201.23 MiB	201.31 MiB	0.04%	279.03 MiB	279.46 MiB	0.15%
🟣 hyper:check	0.1443s	0.1401s	💚 -2.91%	126.42 MiB	126.70 MiB	0.22%	199.79 MiB	199.99 MiB	0.10%
🟣 regex:check	0.3252s	0.3065s	💚 -5.78%	161.87 MiB	161.78 MiB	-0.05%	229.59 MiB	230.23 MiB	0.28%
🟣 syn:check	0.5845s	0.5876s	0.53%	197.01 MiB	196.89 MiB	-0.06%	267.62 MiB	267.47 MiB	-0.06%
Total	1.5367s	1.5169s	💚 -1.29%	686.53 MiB	686.68 MiB	0.02%	976.04 MiB	977.14 MiB	0.11%
Summary	1.0000s	0.9796s	💚 -2.04%	1 byte	1.00 bytes	0.04%	1 byte	1.00 bytes	0.12%

Benchmark	Before	After		Before	After		Before	After
	Time	Time	%	Physical Memory	Physical Memory	%	Committed Memory	Committed Memory	%
🟠 clap:debug	1.6371s	1.6529s	0.96%	395.58 MiB	396.21 MiB	0.16%	460.98 MiB	461.52 MiB	0.12%
🟠 hyper:debug	0.3248s	0.3210s	💚 -1.16%	155.16 MiB	155.19 MiB	0.02%	219.21 MiB	219.30 MiB	0.04%
🟠 regex:debug	1.0148s	0.9929s	💚 -2.16%	297.96 MiB	295.07 MiB	-0.97%	354.53 MiB	351.58 MiB	-0.83%
🟠 syn:debug	1.3614s	1.3717s	0.76%	319.10 MiB	321.19 MiB	0.65%	378.90 MiB	381.27 MiB	0.62%
Total	4.3381s	4.3386s	0.01%	1.14 GiB	1.14 GiB	-0.01%	1.38 GiB	1.38 GiB	0.00%
Summary	1.0000s	0.9960s	-0.40%	1 byte	1.00 bytes	-0.03%	1 byte	1.00 bytes	-0.01%

[rustbot]

r? @estebank

rustbot has assigned @estebank.
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

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 229e548 with merge 42fea88...

[lqd]

It’s pre-existing and maybe benign but somewhat surprising, is it expected that we only handle a single error in this function? Either way, this looks to now return a random error?

[Zoxc]

Yeah. It's only used with ErrorGuaranteed. All the errors are equivalent.

[lqd]

Cool. Let's add that explanation as a comment.

[RalfJung]

In parallel loops, instead of a Rayon iterator a serial iterator are used to collect items into a Vec and we use a parallel loop over its elements using the new par_slice function which is built on rustc-rayon-core's join.

This change makes it easier to bring rustc-rayon-core in-tree.

That seems like a step backwards. Why is "bring rustc-rayon-core in-tree" so desirable that we should stop using well-tested and well-working ecosystem crates? I feel like there's some broader context here that the PR description fails to explain.

[bors]

☀️ Try build successful - checks-actions
Build commit: 42fea88 (42fea88737205de5b0f9a6ebbea8a2081f6134f3)

[klensy]

well-tested and well-working ecosystem crates

But this isn't rayon, this is rustc-rayon, few years outdated fork with some custom patches.

[RalfJung]

So "rayon iterators" are not the iterators from rayon? Given that a bunch of people got auto-pinged here, it would be good to make the PR description understandable to the general compiler team, not just people with intimate knowledge of parallel-rustc. :)

[rust-timer]

Finished benchmarking commit (42fea88): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.2%, secondary 2.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	1
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

Cycles

Results (secondary 3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.0%	[2.0%, 3.5%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 778.377s -> 776.378s (-0.26%)
Artifact size: 365.79 MiB -> 365.78 MiB (-0.00%)

[bjorn3]

Suggested change

	IntoDynSyncSend(
	tcx.dep_graph
	.with_task(
	dep_node,
	tcx,
	(
	global_asm_config.clone(),
	cgu.name(),
	concurrency_limiter.acquire(tcx.dcx()),
	),
	module_codegen,
	Some(rustc_middle::dep_graph::hash_result),
	)
	.0,
	)
	let (module, _) = tcx.dep_graph
	.with_task(
	dep_node,
	tcx,
	(global_asm_config.clone(), cgu.name(), concurrency_limiter.acquire(tcx.dcx())),
	module_codegen,
	Some(rustc_middle::dep_graph::hash_result),
	);
	IntoDynSyncSend(module)

reduces indentation and avoids rustfmt putting the tcx.sess.time() call on a separate indented line.

[cuviper]

In parallel loops, instead of a Rayon iterator a serial iterator are used to collect items into a Vec and we use a parallel loop over its elements using the new par_slice function which is built on rustc-rayon-core's join.

Maybe we should have a bespoke lighter version of IntoParallelIterator that still lets some types work directly in this par_slice mode? Then you can have uses on &[T] and &mut [T] without any serial collect, but also for example on indexmap with its own Slice types.

[cuviper]

I think you would just need:

trait ParSplit: IntoIterator + DynSend + Sized {
    fn len(&self) -> usize;
    fn split_at(self, at: usize) -> (Self, Self);
}

[Zoxc]

That seems like a step backwards. Why is "bring rustc-rayon-core in-tree" so desirable that we should stop using well-tested and well-working ecosystem crates?

I'm basically replacing the Rayon iterators with 36 lines of code here. It doesn't have high value in rustc's code base.

Maybe we should have a bespoke lighter version of IntoParallelIterator that still lets some types work directly in this par_slice mode?

Probably want some variant that would work with loops, not just join. Having loop support in the thread pool would allow work-stealing within the loop.

[RalfJung]

I'm basically replacing the Rayon iterators with 36 lines of code here. It doesn't have high value in rustc's code base.

Ah okay, I thought there's all the attached infrastructure (threadpool etc) that we'd then have to carry ourselves. But if we do that already anyway then sounds good to me.

[bjorn3]

The threadpool is implemented by rayon-core, of which this PR still retains the rustc fork (rustc-rayon-core, necessary because upstream rayon doesn't support propagating thread local storage to the worker threads among other things).