Optimize impl_read_unsigned_leb128

[nnethercote]

I see instruction count improvements of up to 3.5% locally with these changes, mostly on the smaller benchmarks.

r? @michaelwoerister

[nnethercote]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit ac6e14fe68386ccb4988623104c2f36f2fdcdbb9 with merge 2817d16b0dd82139c66514d1ed9609a37366c53d...

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit a18ddee2ead17a25fd616314fd0e30524b5fd04e with merge 7775b1f299a2e55b29c22ee1c04e4b31a08e34f8...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7775b1f299a2e55b29c22ee1c04e4b31a08e34f8 (7775b1f299a2e55b29c22ee1c04e4b31a08e34f8)

[rust-timer]

Queued 7775b1f299a2e55b29c22ee1c04e4b31a08e34f8 with parent f1ce0e6, future comparison URL.

[rust-timer]

Finished benchmarking commit (7775b1f299a2e55b29c22ee1c04e4b31a08e34f8): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -2.2% on incr-unchanged builds of ucd)
• Moderate regression in instruction counts (up to 1.4% on incr-unchanged builds of ctfe-stress-4)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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-review -S-waiting-on-perf +perf-regression

[michaelwoerister]

Is that true for all types? IIRC, that's very common for usize but much less so for u64, for example. Maybe it would make sense to have two implementations, one optimized for small values and another optimized for larger values?

[Kobzol]

Indeed it could be a good idea to generalize the impl for various "categories" of numbers (often small, often large), it helped recently in hashing: #92103.

[nnethercote]

Good point! I did some follow-up investigation, and saw that this accounts for the regressions seen in some cases. For example, the ctfe-stress-4 check incr-unchanged regression seen on the CI run has this distribution of leb128 lengths for read u64 values:

2361790 counts:
(  1)  1311716 (55.5%, 55.5%): u64 1
(  2)  1049356 (44.4%,100.0%): u64 10
(  3)      574 ( 0.0%,100.0%): u64 9
(  4)      115 ( 0.0%,100.0%): u64 2
(  5)       20 ( 0.0%,100.0%): u64 4
(  6)        5 ( 0.0%,100.0%): u64 3
(  7)        3 ( 0.0%,100.0%): u64 8
(  8)        1 ( 0.0%,100.0%): u64 7

[Kobzol]

FWIW, I looked at reading/writing LEB128 recently. I tried two things:

• Removing bound checks (let byte = slice[*position];) from reading: didn't help
• Removing the loop from writing and performing an explicit match on the number of bytes that should be written, like:

match value {
    0..0x7F => leb_write(),
    0x80... => leb_write(), leb_write()
}

etc. It helped for some benchmarks, but in the end it was mostly a regression, probably because the code was much larger. But I think that maybe if a good compromise on the number of branches was found, it could be an improvement, because now the loop is quite tight and the repeated increment can slow it down.

[nnethercote]

I have split out the second commit ("Modify the buffer position directly when reading leb128 values") into its own PR (#92631) because it's a straightforward win for all types. Once that is merged I'll return here and work through the more subtle changes that are type-dependent. Thanks for the feedback.

[nnethercote]

I did some more investigation.

• Modifying the buffer position directly is a universal win, as Modify the buffer position directly when reading leb128 values. #92631 shows.
• Unpeeling the first iteration of the loop is also a universal win, even for u64 and u128. (I tried removing it for just u64 and u128, that made things slightly worse.)
• Putting the loop into a separate function is a regression on a lot of case, so I have ditched that.

So I now have two commits in this PR, and if the CI run works well I think we should land them both here, and drop #92631. Sorry for any confusion!

@bors try @rust-timer queue

[bors]

📌 Commit facba24 has been approved by michaelwoerister

[hjiayz]

https://crates.io/crates/varint-simd
Simd leb128 lib

[bjorn3]

It seems like getting any benefit from that crate requires compiling rustc with at least the ssse3 target feature. Rustc is currently compiled to be suitable for all x86_64 cpu's.

[bors]

⌛ Testing commit facba24 with merge e7fc933df9c0bfd4e10cc827cdcf6bb44afb4769...

[bors]

💥 Test timed out

[lqd]

@bors retry Test timed out

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

⌛ Testing commit facba24 with merge 1078f1d405bf2eacdfc6efb40f0ef7aa797cbabf...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[lqd]

@bors retry Some apple builder is having network issues. "unable to access 'https://github.com/rust-lang-ci/rust/': Could not resolve host: github.com"

[bors]

⌛ Testing commit facba24 with merge 38c22af...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing 38c22af to master...

[rust-timer]

Finished benchmarking commit (38c22af): comparison url.

Summary: This change led to large relevant improvements 🎉 in compiler performance.

• Large improvement in instruction counts (up to -3.6% on full builds of helloworld)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression