Better sso structures

[VFLashM]

This change greatly expands interface of MiniSet/MiniMap and renames them because they are no longer "Mini".

[rust-highfive]

r? @oli-obk

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

[oli-obk]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 1046efb1dd1e7739fea89f4717b64ede06478647 with merge 756b88018c71526ac1998d6368cd4886d88cdb73...

[oli-obk]

I'll review in a bit, but let's launch perfbot in parallel

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 756b88018c71526ac1998d6368cd4886d88cdb73 (756b88018c71526ac1998d6368cd4886d88cdb73)

[rust-timer]

Queued 756b88018c71526ac1998d6368cd4886d88cdb73 with parent fadf025, future comparison URL.

[Mark-Simulacrum]

FYI, this try build might be a bit noisier or affected by more than just the PR itself, as we just applied some de-noising on the server. So it might make sense to re-create a try build, especially if perf is a blocking concern for whatever reason.

[oli-obk]

Why is this not just a wrapper struct around SsoHashMap<T, ()>?

[VFLashM]

That's actually a good idea.
Sure, it's already a thin wrap, but it could be even thinner.
Let me try that.

[oli-obk]

Ah 😆 I thought there was a reason and just wanted it documented. Maybe let's do that in a separate step, since we already have a perf situation

[rust-timer]

Finished benchmarking try commit (756b88018c71526ac1998d6368cd4886d88cdb73): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[oli-obk]

Just to be sure that's not due to the recent perf changes:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 1046efb1dd1e7739fea89f4717b64ede06478647 with merge f42f07c1222f0c090836b569b9de3e508c571e1b...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: f42f07c1222f0c090836b569b9de3e508c571e1b (f42f07c1222f0c090836b569b9de3e508c571e1b)

[rust-timer]

Queued f42f07c1222f0c090836b569b9de3e508c571e1b with parent b984ef6, future comparison URL.

[rust-timer]

Finished benchmarking try commit (f42f07c1222f0c090836b569b9de3e508c571e1b): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[oli-obk]

So it's not noise. Typeck deserialization from incremental caches is affected

[VFLashM]

I'm really surprised by the result.
I barely changes existing functions, mostly just added new ones.
I'll have to check it once again.

[oli-obk]

Maybe inlining changed? That can be very subtle and happen due to minor changes

[VFLashM]

Hmm. I can't reproduce this result locally:

Any suggestions?

Here are the changes compared to previous version:

1. Map::insert now returns old value if any whereas before it returned nothing
2. Map::get used to accept key type directly, now it accepts some type which can be borrowed as key.
3. Array iteration unpacks key/value tuple instead of iterating over pairs (not sure if it matters)

[oli-obk]

I can't tell from the code changes (where the map/set is used) how this could affect incremental cache loading times. I'm guessing it's all spurious. So, let's go with: rebase, change the set impl to just forward to the map impl, run perf again. Does that sound reasonable to you?

[VFLashM]

Yup, let me do just that.

[bors]

⌛ Trying commit 41942fa with merge f19b20c14696f331a43042bde62219a773d43ba4...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: f19b20c14696f331a43042bde62219a773d43ba4 (f19b20c14696f331a43042bde62219a773d43ba4)

[rust-timer]

Queued f19b20c14696f331a43042bde62219a773d43ba4 with parent c9e5e6a, future comparison URL.

[rust-timer]

Finished benchmarking try commit (f19b20c14696f331a43042bde62219a773d43ba4): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[VFLashM]

Sigh. Trying to reproduce it locally one more time.
Which configuration does rustc-perf use?

[VFLashM]

I reproduced it locally.
It only happens on stage2 compiler and I performed all my tests on stage 1.

Am I missing something?
Shouldn't stage 1 be enough to benchmark?
Given that this change is a pure performance optimization, I'd expect that stage 1 and stage 2 compilers would be the same.

[oli-obk]

The only thing I can come up with is that this is not a regression in this PR, but this PR is just a symptom of a regression from the beta (bootstrap) compiler to master. So master doesn't optimize your changes as well as they were optimized on beta. Can you try this out by rebasing onto the master branch from just when the mini maps were introduced and rerunning perf on stage 2? Or is that not long enough ago to make a difference?

cc @rust-lang/wg-compiler-performance @rust-lang/wg-codegen any ideas what's going on? do we have any perf regressions maybe due to an llvm upgrade or something?

[VFLashM]

Yeah, they were introduced just recently.

I think I narrowed it down.

When I remove generality over Q from SsoHashMap::get (as in make it accept &K for key), performance jumps back to expected levels. I thought that maybe additional borrow messes up inlining and tried marking SsoHashMap::get as #[inline]. Doing so cuts performance penalty in half, but doesn't remove it. This doesn't make sense as borrow should be an inlined NOP.

I'm out good of ideas by now. What would be the best way to inspect assembly output sans for disassembling rust?

[oli-obk]

#[inline] is just a hint, so I'm guessing that sometimes the forwarding to FxHashMap::get will get inlined and sometimes not. Sometimes SsoHashMap::get gets inlined, sometimes not. So there are many combinations where this can go "wrong". Maybe we merge the manually monomorphized version for now and then track making it generic again? At this point I'm wondering whether it may make sense to pull this out into a crate with its own unit tests so we can run benchmarks, valgrind and similar tooling on it.

[VFLashM]

Pushed a change. Removed Q generic, all methods now accept &K directly.

[oli-obk]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit d1d2184 with merge 3580ee5afaa5d6dc265216653a63bdd35ebe828c...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 3580ee5afaa5d6dc265216653a63bdd35ebe828c (3580ee5afaa5d6dc265216653a63bdd35ebe828c)

[rust-timer]

Queued 3580ee5afaa5d6dc265216653a63bdd35ebe828c with parent efbaa41, future comparison URL.

[rust-timer]

Finished benchmarking try commit (3580ee5afaa5d6dc265216653a63bdd35ebe828c): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[oli-obk]

@bors r+

Thanks, this looks good now. Wrt the constant that decides the array size, you could make it a const generic parameter in a follow-up PR if you think making it configurable is useful per-site.

[bors]

📌 Commit d1d2184 has been approved by oli-obk

[bors]

⌛ Testing commit d1d2184 with merge ea7e131...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing ea7e131 to master...