Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove a large amount of leb128-coded integers #119791

Merged
merged 2 commits into from Jan 11, 2024

Conversation

Mark-Simulacrum
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum commented Jan 10, 2024

This removes ~41%1 of the leb128-encoded integers serialized during libcore compilation by changing enum tags to opportunistically use u8 where feasible instead of the leb128 coding via usize.

This should have effectively zero impact on metadata file sizes, since almost all or all enum tags fit into the 7 bits available in leb128 for single-byte encodings. Perf results indicate this is basically neutral across the board except for an improvement in bootstrap time.

Footnotes

  1. More than half the remaining integers still fit into <= 128, so the leb128 coding still makes sense. 32% are zero, and 46% are <= 4.

100% of the serialized enums during libcore compilation fit into the
smaller tag, and this eliminates hitting the leb128 code for
coding/decoding when we can statically guarantee that's not required.

30% of all leb128 integers serialized in libcore (12981183 total) come
from the usize's removed here.
This removes emit_enum_variant and the emit_usize calls that resulted
in. In libcore this eliminates 17% of leb128, taking us from 8964488 to
7383842 leb128's serialized.
@rustbot
Copy link
Collaborator

rustbot commented Jan 10, 2024

r? @cjgillot

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 10, 2024
@rustbot

This comment was marked as resolved.

@Mark-Simulacrum
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 10, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 10, 2024
Remove a large amount of leb128-coded integers

This removes ~41%[^1] of the leb128-encoded integers serialized during libcore compilation by changing enum tags to opportunistically use `u8` where feasible instead of the leb128 coding via `usize`.

This should have effectively zero impact on metadata file sizes, since almost all or all enum tags fit into the 7 bits available in leb128 for single-byte encodings, but my hope (as yet untested) is that this is a win for compilation times (by eliminating branches, if predictable ones) and possibly compiler's code size (via more branch elimination).

[^1]: More than half the remaining integers still fit into <= 128, so the leb128 coding still makes sense. 32% are zero, and 46% are <= 4.
@bors
Copy link
Contributor

bors commented Jan 10, 2024

⌛ Trying commit 1d2005b with merge 78bd79d...

@bors
Copy link
Contributor

bors commented Jan 10, 2024

☀️ Try build successful - checks-actions
Build commit: 78bd79d (78bd79dedcac84ebf4531777a0dd4a436723736c)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (78bd79d): 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.3% [0.3%, 0.3%] 2
Regressions ❌
(secondary)
0.6% [0.6%, 0.6%] 1
Improvements ✅
(primary)
-0.3% [-0.5%, -0.2%] 7
Improvements ✅
(secondary)
-0.4% [-0.7%, -0.1%] 14
All ❌✅ (primary) -0.2% [-0.5%, 0.3%] 9

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.2% [1.2%, 1.2%] 1
Regressions ❌
(secondary)
1.8% [1.8%, 1.8%] 1
Improvements ✅
(primary)
-0.5% [-0.5%, -0.5%] 1
Improvements ✅
(secondary)
-3.0% [-3.0%, -3.0%] 1
All ❌✅ (primary) 0.4% [-0.5%, 1.2%] 2

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)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.5%, -0.5%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.5% [-0.5%, -0.5%] 1

Binary size

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

Bootstrap: 667.55s -> 665.141s (-0.36%)
Artifact size: 308.58 MiB -> 308.49 MiB (-0.03%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jan 10, 2024
@Mark-Simulacrum
Copy link
Member Author

Seems like this is pretty much neutral on everything except bootstrap times, presuming the delta there isn't noise. I think we should move ahead with it though.

@cjgillot
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jan 11, 2024

📌 Commit 1d2005b has been approved by cjgillot

It is now in the queue for this repository.

@bors 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 Jan 11, 2024
@bors
Copy link
Contributor

bors commented Jan 11, 2024

⌛ Testing commit 1d2005b with merge 68acb39...

@bors
Copy link
Contributor

bors commented Jan 11, 2024

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 68acb39 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 11, 2024
@bors bors merged commit 68acb39 into rust-lang:master Jan 11, 2024
12 checks passed
@rustbot rustbot added this to the 1.77.0 milestone Jan 11, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (68acb39): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Regressions ❌
(secondary)
1.1% [1.1%, 1.1%] 1
Improvements ✅
(primary)
-0.3% [-0.3%, -0.2%] 5
Improvements ✅
(secondary)
-0.3% [-0.5%, -0.1%] 12
All ❌✅ (primary) -0.3% [-0.3%, -0.2%] 5

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.7% [1.7%, 1.7%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.4% [-0.4%, -0.4%] 1
Improvements ✅
(secondary)
-1.4% [-1.4%, -1.4%] 2
All ❌✅ (primary) 0.7% [-0.4%, 1.7%] 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: 666.77s -> 665.325s (-0.22%)
Artifact size: 308.45 MiB -> 308.34 MiB (-0.04%)

@rustbot rustbot removed the perf-regression Performance regression. label Jan 11, 2024
@Mark-Simulacrum Mark-Simulacrum deleted the cut-leb128 branch January 11, 2024 23:50
@pnkfelix
Copy link
Member

  • the 1.1% hit is to deep-vector debug full. It may be transient; the history is pretty up-and-down at the time of this PR, and has settled at a lower level than where it was when this PR landed.
  • in any case, the gains elsewhere, especially bootstrap, outweigh the loss to that one secondary benchmark. (Which ... I guess is what the rustc-perf bot now computes as well?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants