Use <[T; N]>::map in Sharded instead of SmallVec and unsafe code

[bjorn3]

This results in a lot less assembly

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 7b50fd5 with merge d7e5e4ab57e3fa2aca41f679c8baab3581926670...

[Mark-Simulacrum]

Probably doesn't matter too much for perf - I don't think we frequently initialize Sharded - but r=me, seems like a good improvement if perf is good.

[bors]

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

[rust-timer]

Queued d7e5e4ab57e3fa2aca41f679c8baab3581926670 with parent 6cdd42f, future comparison URL.

[rust-timer]

Finished benchmarking commit (d7e5e4ab57e3fa2aca41f679c8baab3581926670): comparison url.

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

• Moderate improvement in instruction counts (up to -1.4% on incr-unchanged builds of ctfe-stress-4)
• Moderate regression in instruction counts (up to 0.7% on incr-patched: println builds of coercions)

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

[bjorn3]

A couple of regressions, mostly improvements.

[Mark-Simulacrum]

Looking at a cachegrind diff locally, the regression seems to be caused by noise rather than something genuine -- I'm seeing a bump in the number of instructions used for PartialEq ConstKind not equals, which seems pretty unrelated to this change, and some LLVM functions. Ultimately doesn't seem like this is something we can address and the change does bring a win on both how simple the code is and bootstrap compilation time.

@rustbot label +perf-regression-triaged

@bors r+

[bors]

📌 Commit 7b50fd5 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 7b50fd5 with merge 3bb9eec...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 3bb9eec to master...

[rust-timer]

Finished benchmarking commit (3bb9eec): comparison url.

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

• Moderate improvement in instruction counts (up to -1.1% on full builds of coercions)
• Large regression in instruction counts (up to 2.8% on incr-full builds of ctfe-stress-4)

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

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[pnkfelix]

Visiting for performance triage.

The report from when this PR was first timed looks pretty different from the report from when it landed.

But either way, I'm inclined to apply @Mark-Simulacrum 's analysis above.

@rustbot label: +perf-regression-triaged