-
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
Streamline size estimates #113684
Streamline size estimates #113684
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit adcfd93f0aa9b387f91a10e9dc49c5dc189572a0 with merge eb0596b60545ce2c3ac92dd2aafb5713910aeca4... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
adcfd93
to
f2d28cc
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit f2d28cc15b1a20c5a5b93031eb5d3cf110c61497 with merge a861e61c1dc3fcf632860ee8946626d8945d9bd9... |
☀️ Try build successful - checks-actions |
// "Normal" functions size estimate: the number of | ||
// statements, plus one for the terminator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, seeing this code again reminded me of something that occurred to me while reading your recent blog post: should we have different size estimates for codegen with and without optimizations enabled?
I could believe this current estimate is relatively accurate for debug builds but many optimization passes in LLVM are non-linear with regards to the number of basic blocks. Perhaps it makes sense to use different estimation strategies when we are optimizing code and not optimizing code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tried a variety of alternative estimation functions. #113047 and #113649 are two that I filed PRs for, and I've tried a bunch more locally. I can't say that I ever really saw meaningful differences between release and debug builds. Cleverer estimation functions have gotten me exactly zero wins at the moment, so I'm inclined to not spend more effort there :)
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the next commit will add another field.
This means we call `MonoItem::size_estimate` (which involves a query) less often: just once per mono item, and then once more per inline item placement. After that we can reuse the stored value as necessary. This means `CodegenUnit::compute_size_estimate` is cheaper.
They're quite rare, and ignoring them simplifies things quite a bit, and further reduces the number of calls to `MonoItem::size_estimate` to the number of placed items (one per root item, and one or more per reachable inlined item).
It doesn't seem worthwhile now that `MonoItem::size_estimate` is called much less often.
f2d28cc
to
f4c4602
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (eb0596b60545ce2c3ac92dd2aafb5713910aeca4): comparison URL. Overall result: no relevant changes - 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 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.
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: 657.803s -> 657.535s (-0.04%) |
@bors r=wesleywiser |
☀️ Test successful - checks-actions |
Finished benchmarking commit (bef6ff6): 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: 657.64s -> 657.713s (0.01%) |
There has been a bors issue that lead to the merge commit of this PR getting purged from master. |
…s-2, r=wesleywiser Streamline size estimates (take 2) This was merged in rust-lang#113684 but then [something happened](rust-lang#113684 (comment)): > There has been a bors issue that lead to the merge commit of this PR getting purged from master. > You'll have to make a new PR to reapply it. So this is exactly the same changes. `@bors` r=wesleywiser
Makes things nicer and a tiny bit faster.
r? @wesleywiser