Improve VecCache under parallel frontend #124780

Mark-Simulacrum · 2024-05-06T00:19:12Z

This replaces the single Vec allocation with a series of progressively larger buckets. With the cfg for parallel enabled but with -Zthreads=1, this looks like a slight regression in i-count and cycle counts (~1%).

With the parallel frontend at -Zthreads=4, this is an improvement (-5% wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based approach, likely due to reducing the bouncing of the cache line holding the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319 seconds).

try-job: i686-gnu-nopt
try-job: dist-x86_64-linux

Mark-Simulacrum · 2024-05-06T00:19:56Z

@bors try @rust-timer queue

bors · 2024-05-06T00:21:07Z

⌛ Trying commit 206251b with merge 15ee677...

[WIP] Improve VecCache under parallel frontend This replaces the single Vec allocation with a series of progressively larger buckets. With the cfg for parallel enabled but with -Zthreads=1, this looks like a slight regression in i-count and cycle counts (<0.1%). With the parallel frontend at -Zthreads=4, this is an improvement (-5% wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based approach, likely due to reducing the bouncing of the cache line holding the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319 seconds). FIXME: Extract the internals to rustc_data_structures, safety comments, etc. r? `@Mark-Simulacrum` -- opening for perf first.

bors · 2024-05-06T01:57:44Z

☀️ Try build successful - checks-actions
Build commit: 15ee677 (15ee67784efd5d46670c56f52fd618a4a00771e5)

Zoxc · 2024-05-06T03:13:07Z

compiler/rustc_query_system/src/query/caches.rs

+
+impl SlotIndex {
+    #[inline]
+    fn from_index(idx: u32) -> Self {


Have you tried to write a branchless version of this?

The result of this on x86 at least is branchless (with conditional moves): https://rust.godbolt.org/z/x9s3aexYh

Zoxc · 2024-05-06T04:38:30Z

compiler/rustc_query_system/src/query/caches.rs

+        let index = match current {
+            0 => return None,
+            // Treat "initializing" as actually just not initialized at all.
+            // The only reason this is a separate state is that `complete` calls could race and


Because we ensure that each query only executes once, complete will only be called once per key, so this race can't happen.

I would prefer to avoid a non-local safety condition like that. The performance gain from avoiding a true lock here isn't meaningful anyway.

rust-timer · 2024-05-06T17:30:03Z

Finished benchmarking commit (15ee677): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.2%, 2.9%]	169
Regressions ❌ (secondary)	0.9%	[0.2%, 2.3%]	70
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-2.3%, -0.4%]	5
All ❌✅ (primary)	0.8%	[0.2%, 2.9%]	169

Max RSS (memory usage)

Results

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)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	3.0%	[2.6%, 3.8%]	4
Improvements ✅ (primary)	-3.0%	[-7.1%, -1.1%]	54
Improvements ✅ (secondary)	-8.2%	[-13.3%, -4.6%]	22
All ❌✅ (primary)	-2.9%	[-7.1%, 1.8%]	55

Cycles

Results

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)	1.2%	[0.8%, 2.1%]	13
Regressions ❌ (secondary)	2.4%	[1.4%, 3.2%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.2%	[0.8%, 2.1%]	13

Binary size

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

Bootstrap: 676.55s -> 678.643s (0.31%)
Artifact size: 315.72 MiB -> 316.01 MiB (0.09%)

Mark-Simulacrum · 2024-06-09T21:55:46Z

@bors try @rust-timer queue

No major changes, but let's collect another more recent run. Presuming results are about the same I'll mark this ready for review, the improvement in scalability IMO outweighs slight regressions to single-threaded compilation.

Improve VecCache under parallel frontend This replaces the single Vec allocation with a series of progressively larger buckets. With the cfg for parallel enabled but with -Zthreads=1, this looks like a slight regression in i-count and cycle counts (~1%). With the parallel frontend at -Zthreads=4, this is an improvement (-5% wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based approach, likely due to reducing the bouncing of the cache line holding the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319 seconds).

bors · 2024-06-09T21:56:57Z

⌛ Trying commit a28ef6f with merge d447427...

bors · 2024-06-09T23:30:11Z

☀️ Try build successful - checks-actions
Build commit: d447427 (d447427ec5ed8db4f1baad0135b5304baef82ce9)

rust-timer · 2024-06-10T01:59:41Z

Finished benchmarking commit (d447427): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.2%, 2.6%]	171
Regressions ❌ (secondary)	1.1%	[0.2%, 10.0%]	99
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-5.2%, -0.4%]	8
All ❌✅ (primary)	0.7%	[0.2%, 2.6%]	171

Max RSS (memory usage)

Results (primary -3.4%, secondary -8.1%)

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.2%	[2.5%, 3.9%]	2
Improvements ✅ (primary)	-3.4%	[-8.2%, -0.9%]	70
Improvements ✅ (secondary)	-9.2%	[-14.0%, -3.3%]	21
All ❌✅ (primary)	-3.4%	[-8.2%, -0.9%]	70

Cycles

Results (primary 2.2%, secondary 2.3%)

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)	2.2%	[1.5%, 3.1%]	17
Regressions ❌ (secondary)	2.3%	[1.4%, 2.9%]	22
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.2%	[1.5%, 3.1%]	17

Binary size

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

Bootstrap: missing data
Artifact size: 319.77 MiB -> 319.42 MiB (-0.11%)

Mark-Simulacrum · 2024-06-15T14:42:13Z

r? compiler

As noted in the PR description this is a regression for cycles/time on non-parallel builds (more code to execute). That's largely offset by far better scalability to more threads in parallel compilers. I think the trade-off is worth it, particularly since this also appears to be a memory usage win.

lcnr · 2024-11-15T12:22:06Z

compiler/rustc_data_structures/src/vec_cache/tests.rs

+    // tests.
+    for power in 0..25 {
+        let key = 1u32 << power;
+        cache.complete(key, (), key);


can you also add a lookup here to make sure lookup is also correct for later buckets?

This replaces the single Vec allocation with a series of progressively larger buckets. With the cfg for parallel enabled but with -Zthreads=1, this looks like a slight regression in i-count and cycle counts (<0.1%). With the parallel frontend at -Zthreads=4, this is an improvement (-5% wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based approach, likely due to reducing the bouncing of the cache line holding the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319 seconds).

Mark-Simulacrum · 2024-11-16T17:31:56Z

This would instead require us to adjust the tests to not reach the isize::MAX limit on 32 bit targets 🤔 i think an abort here is totally acceptable as we already abort if the layout is small enough, but we fail to allocate

Yeah, that seems obvious now that you say it :)

Pushed up a revert of most of the 32-bit changes, we were already aborting/panicking on allocation failure so I think most of those changes weren't even necessary in the first place, we just needed to avoid the tests hitting the LayoutError -- which we now do, tweaking to test the full (sparse) range on 64-bit Linux and otherwise limiting to a smaller range to avoid wasting a bunch of memory.

@bors try @rust-timer queue

Mark-Simulacrum · 2024-11-16T18:35:37Z

@bors try

Mark-Simulacrum · 2024-11-17T15:55:30Z

@bors try

Mark-Simulacrum · 2024-11-17T15:56:19Z

@bors try

Hopefully this works, I think bors forgot about the PR...

Improve VecCache under parallel frontend This replaces the single Vec allocation with a series of progressively larger buckets. With the cfg for parallel enabled but with -Zthreads=1, this looks like a slight regression in i-count and cycle counts (~1%). With the parallel frontend at -Zthreads=4, this is an improvement (-5% wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based approach, likely due to reducing the bouncing of the cache line holding the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319 seconds). try-job: i686-gnu-nopt try-job: dist-x86_64-linux

bors · 2024-11-17T15:57:32Z

⌛ Trying commit da58efb with merge a185d27...

bors · 2024-11-17T17:44:47Z

☀️ Try build successful - checks-actions
Build commit: a185d27 (a185d27b07d8de5f7a07525cef0701b8364b4862)

rust-timer · 2024-11-17T19:02:09Z

Finished benchmarking commit (a185d27): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@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)	1.0%	[0.2%, 3.3%]	214
Regressions ❌ (secondary)	1.1%	[0.2%, 3.0%]	165
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-3.1%, -0.1%]	9
All ❌✅ (primary)	1.0%	[0.2%, 3.3%]	214

Max RSS (memory usage)

Results (primary -2.9%, secondary -2.1%)

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)	2.3%	[1.6%, 2.8%]	4
Regressions ❌ (secondary)	3.1%	[0.7%, 7.5%]	24
Improvements ✅ (primary)	-3.2%	[-6.9%, -0.8%]	85
Improvements ✅ (secondary)	-6.4%	[-12.5%, -1.7%]	29
All ❌✅ (primary)	-2.9%	[-6.9%, 2.8%]	89

Cycles

Results (primary 2.1%, secondary 2.7%)

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)	2.1%	[1.0%, 4.5%]	31
Regressions ❌ (secondary)	2.7%	[1.2%, 5.2%]	23
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[1.0%, 4.5%]	31

Binary size

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

Bootstrap: 787.86s -> 792.684s (0.61%)
Artifact size: 335.54 MiB -> 335.95 MiB (0.12%)

lcnr

r=me if you're happy with perf

Mark-Simulacrum · 2024-11-19T01:26:13Z

@bors r=lcnr

Yeah, within reasonable bounds, though obviously still room for improvement.

bors · 2024-11-19T01:26:15Z

📌 Commit da58efb has been approved by lcnr

It is now in the queue for this repository.

bors · 2024-11-19T02:07:51Z

⌛ Testing commit da58efb with merge 5926e82...

bors · 2024-11-19T05:13:36Z

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 5926e82 to master...

rust-timer · 2024-11-19T06:30:49Z

Finished benchmarking commit (5926e82): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	1.0%	[0.2%, 3.3%]	214
Regressions ❌ (secondary)	1.0%	[0.2%, 2.9%]	172
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.9%	[-3.0%, -0.4%]	8
All ❌✅ (primary)	1.0%	[0.2%, 3.3%]	214

Max RSS (memory usage)

Results (primary -3.0%, secondary -2.7%)

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)	2.8%	[2.0%, 4.1%]	5
Regressions ❌ (secondary)	3.6%	[1.8%, 8.6%]	16
Improvements ✅ (primary)	-3.3%	[-7.5%, -1.2%]	82
Improvements ✅ (secondary)	-6.3%	[-12.4%, -1.5%]	28
All ❌✅ (primary)	-3.0%	[-7.5%, 4.1%]	87

Cycles

Results (primary 2.0%, secondary 2.1%)

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)	2.1%	[1.0%, 4.1%]	29
Regressions ❌ (secondary)	2.6%	[1.8%, 3.8%]	27
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-2.2%	[-3.1%, -1.4%]	3
All ❌✅ (primary)	2.0%	[-2.0%, 4.1%]	30

Binary size

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

Bootstrap: 792.184s -> 793.779s (0.20%)
Artifact size: 334.48 MiB -> 335.25 MiB (0.23%)

pnkfelix · 2024-11-20T02:52:51Z

Visiting for rustc-perf triage

As a quick process note: I'm not sure it was a great idea for @Mark-Simulacrum to add the rustc-perf-triaged label back on June 15th (i.e. before this had landed and in fact before it had gotten r+'ed), because in theory that could cause us to miss a case where new commits are added and the regression effectively becomes untriaged.

But having said that, ...

... as far as I can tell, the regression here remains roughly within the bounds that were anticipated back when this PR's description was first composed... back circa june ~~15th~~ 9th we were looking at a worst case of 2.60% and a mean of 0.7%, while now it is a worst case of 3.3% and a mean of 1.0%...

so that all seems ballpark within what was anticipated, and the expected gains for parallel compilation performance probably justify paying this cost as it stands.

So, I'll leave the rustc-perf-triaged label in place.

rustbot assigned Mark-Simulacrum May 6, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 6, 2024

This comment has been minimized.

Sign in to view

Zoxc reviewed May 6, 2024

View reviewed changes

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels May 6, 2024

Mark-Simulacrum force-pushed the lockless-cache branch from 206251b to a28ef6f Compare June 9, 2024 21:44

Mark-Simulacrum changed the title ~~[WIP] Improve VecCache under parallel frontend~~ Improve VecCache under parallel frontend Jun 9, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 9, 2024

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 10, 2024

Mark-Simulacrum force-pushed the lockless-cache branch from a28ef6f to f73ad9b Compare June 15, 2024 14:39

lcnr reviewed Nov 15, 2024

View reviewed changes

Mark-Simulacrum force-pushed the lockless-cache branch from 1961749 to da58efb Compare November 16, 2024 17:30

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 16, 2024

Mark-Simulacrum closed this Nov 17, 2024

Mark-Simulacrum reopened this Nov 17, 2024

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 17, 2024

lcnr reviewed Nov 18, 2024

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 19, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 19, 2024

bors merged commit 5926e82 into rust-lang:master Nov 19, 2024
13 checks passed

rustbot added this to the 1.84.0 milestone Nov 19, 2024

Mark-Simulacrum deleted the lockless-cache branch November 23, 2024 15:49

Improve VecCache under parallel frontend #124780

Improve VecCache under parallel frontend #124780

Conversation

Mark-Simulacrum commented May 6, 2024 • edited Loading

Mark-Simulacrum commented May 6, 2024

This comment has been minimized.

bors commented May 6, 2024

This comment has been minimized.

bors commented May 6, 2024

This comment has been minimized.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rust-timer commented May 6, 2024

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Mark-Simulacrum commented Jun 9, 2024

This comment has been minimized.

bors commented Jun 9, 2024

bors commented Jun 9, 2024

This comment has been minimized.

rust-timer commented Jun 10, 2024

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Mark-Simulacrum commented Jun 15, 2024

Choose a reason for hiding this comment

Mark-Simulacrum commented Nov 16, 2024

This comment has been minimized.

Mark-Simulacrum commented Nov 16, 2024

Mark-Simulacrum commented Nov 17, 2024

Mark-Simulacrum commented Nov 17, 2024

bors commented Nov 17, 2024

bors commented Nov 17, 2024

This comment has been minimized.

rust-timer commented Nov 17, 2024

Overall result: ❌✅ regressions and improvements - please read the text below

lcnr left a comment

Choose a reason for hiding this comment

Mark-Simulacrum commented Nov 19, 2024

bors commented Nov 19, 2024

bors commented Nov 19, 2024

bors commented Nov 19, 2024

rust-timer commented Nov 19, 2024

Overall result: ❌✅ regressions and improvements - please read the text below

pnkfelix commented Nov 20, 2024

Mark-Simulacrum commented May 6, 2024 •

edited

Loading