-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Inline a bunch of trivial conditions in parser #122718
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…, r=<try> Inline a bunch of trivial conditions in parser It is often the case that these small, conditional functions, when inlined, reveal notable optimization opportunities to LLVM. While saethlin has done a lot of good work on making these kinds of small functions not need `#[inline]` tags as much, being clearer about what we want inlined will get both the MIR opts and LLVM to pursue it more aggressively. On local perf runs, this seems fruitful. Let's see what rust-timer says. r? `@ghost`
After a bit of additional local testing, I think this may be slightly overzealous, so there's another patch on top that I'd like to try if this turns out to not be as exciting. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (5fa0a16): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 668.321s -> 667.844s (-0.07%) |
Not quite as exciting as I hoped but an acceptable result I guess. Let's try a slight variant to see if my intuition is correct: @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…, r=<try> Inline a bunch of trivial conditions in parser It is often the case that these small, conditional functions, when inlined, reveal notable optimization opportunities to LLVM. While saethlin has done a lot of good work on making these kinds of small functions not need `#[inline]` tags as much, being clearer about what we want inlined will get both the MIR opts and LLVM to pursue it more aggressively. On local perf runs, this seems fruitful. Let's see what rust-timer says. r? `@ghost`
I would be surprised if the PGO pipeline didn't already figure out the mostly optimal inlining here. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (a5bf49a): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.309s -> 668.414s (-0.13%) |
There are a bunch of small helper conditionals we use. Inline them to get slightly better perf in a few cases, especially when rustc is compiled without PGO.
Yeah but we don't make the PGO we do easy to apply nor easily replicable, so many rustcs don't have it. |
0033de1
to
140b4c6
Compare
r? compiler |
this doesn't result in significant improvements but also shouldn't hurt @bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (03994e4): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.146s -> 674.027s (0.28%) |
It is often the case that these small, conditional functions, when inlined, reveal notable optimization opportunities to LLVM. While saethlin has done a lot of good work on making these kinds of small functions not need
#[inline]
tags as much, being clearer about what we want inlined will get both the MIR opts and LLVM to pursue it more aggressively.On local perf runs, this seems fruitful. Let's see what rust-timer says.
r? @ghost