Use index newtyping for TyVid

[Mark-Simulacrum]

This is useful for using TyVid in types like VecGraph, and just otherwise seems like a small win.

[rust-highfive]

r? @nagisa

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

[jackh726]

One small nit, but r=me otherwise

[jackh726]

r? @jackh726

[Mark-Simulacrum]

@bors r=jackh726

[bors]

📌 Commit 2eac09d has been approved by jackh726

[jackh726]

@bors rollup=never

It's possible this is perf sensitive, given TyVids are used practically everywhere.

[bors]

⌛ Testing commit 2eac09d with merge 99db26bb785497c59593b01985d8983e640229d1...

[bors]

💥 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)

[Mark-Simulacrum]

Majority of the builders finished, with distcheck being the odd one out - I'm guessing this is spurious.

@bors retry

[bors]

⌛ Testing commit 2eac09d with merge 69c4aa2...

[bors]

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing 69c4aa2 to master...

[rust-timer]

Finished benchmarking commit (69c4aa2): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 1.7% on full builds of keccak)

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

[Mark-Simulacrum]

Hm, interesting. My guess is the extra checks for from_u32/from_usize being in-range (now that we have some niche bits) are causing the worse performance -- that said, cycle times seem more improved than not (https://perf.rust-lang.org/compare.html?start=73641cd23ba470c6b4dcd72b8d5f62d27c735254&end=69c4aa2901ffadf69deaf91b2f90604bcbc2eb36&stat=cycles%3Au) and generally keccak is more of a stress test than real world code.

I'll try to spend some time with cachegrind investigating this.

[Mark-Simulacrum]

Cachegrind seems to confirm that the index manipulation is the likely cause of the added overhead. I don't think that's worth fixing with unsafe code (and would be difficult to justify).