-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
interpret: refactor projection handling code #99101
Conversation
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
First testing the version that I think is the faster of the two, since it avoids introducing new @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit af4c939cd1568eb13c4d1581664fd8840a90eaaf with merge b9fe2470ecb8d858b78e60c1ab3143012cdef548... |
☀️ Try build successful - checks-actions |
Queued b9fe2470ecb8d858b78e60c1ab3143012cdef548 with parent 6dba4ed, future comparison URL. |
Finished benchmarking commit (b9fe2470ecb8d858b78e60c1ab3143012cdef548): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
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 may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Footnotes |
Ah, of course that doesn't work since I think I really need some valgrind profiles here to even know if |
valgrind diff
most likely an inlining issue, slapping |
Thanks! How do I read that diff? |
yes, that's exactly how to read that diff. I'll try to produce percentages, too, anything that goes to 0% is inlined away |
But then why should place_projection getting more expensive is odd, it does basically the same thing as before... |
af4c939
to
55bab62
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 55bab620a371ab69ac1d8eb76d2a88cb8e04bcc3 with merge 88bfc4522b4c58ab7e03dfeace62a6a358f8837c... |
it may just have gotten inlined into all callers, and thus disappeared from cachegrind. |
☀️ Try build successful - checks-actions |
Queued 88bfc4522b4c58ab7e03dfeace62a6a358f8837c with parent 7d1f57a, future comparison URL. |
☀️ Try build successful - checks-actions |
Queued cdd68a378c6fa7e29eec68b2b63999c5dfc2a3f3 with parent 38b7215, future comparison URL. |
Finished benchmarking commit (cdd68a378c6fa7e29eec68b2b63999c5dfc2a3f3): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
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 may lead to changes in compiler perf. @bors rollup=never Footnotes |
Moves our projection handling code into a common file, and avoids the use of a general mplace-based fallback function by have more specialized implementations. mplace_index (and the other slice-related functions) could be more efficient by copy-pasting the body of operand_index. Or we could do some trait magic to share the code between them. But for now this is probably fine.
dc767b7
to
04b3cd9
Compare
Looks like @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 04b3cd9 with merge da916a909deef1bbb257db0f54cb5347ebdc86b0... |
☀️ Try build successful - checks-actions |
Queued da916a909deef1bbb257db0f54cb5347ebdc86b0 with parent 8a33254, future comparison URL. |
Finished benchmarking commit (da916a909deef1bbb257db0f54cb5347ebdc86b0): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
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 may lead to changes in compiler perf. @bors rollup=never Footnotes |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7b57152): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Moves our projection handling code into a common file, and avoids the use of a
general mplace-based fallback function by have more specialized implementations.
mplace_index (and the other slice-related functions) could be more efficient by
copy-pasting the body of operand_index. Or we could do some trait magic to share
the code between them. But for now this is probably fine.
This is the common part of #99013 and #99097. I am seeing some strange perf results so this probably should be its own change so we know which diff caused which perf changes...
r? @oli-obk