-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 some Cursor calls for slices #60656
Conversation
(Partially) brings back rust-lang#33921
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
These inlines seem plausible to me - what does the assembly look like after this change? |
For that specific example:
vs before:
Like I said, if we're going to merge this we should decide what category in general should be inlined and I should go through the full set for |
Ok awesome, that looks good. The general policy is to inline functions in cases where we see concrete improvements from doing so. @bors r+ |
📌 Commit b9c4301 has been approved by |
…lice, r=sfackler Inline some Cursor calls for slices (Partially) brings back rust-lang#33921 I've noticed in some serialization code I was writing that writes to slices produce much, much, worse code than you'd expect even with optimizations turned on. For example, you'd expect something like this to be zero cost: ``` use std::io::{self, Cursor, Write}; pub fn serialize((a, b): (u64, u64)) -> [u8;8+8] { let mut r = [0u8;16]; { let mut w = Cursor::new(&mut r[..]); w.write(&a.to_le_bytes()).unwrap(); w.write(&b.to_le_bytes()).unwrap(); } r } ``` ...but it compiles down to [dozens of instructions](https://rust.godbolt.org/z/bdwDzb) because the `slice_write()` calls aren't inlined, which in turn means `unwrap()` can't be optimized away, and so on. To be clear, this pull-req isn't sufficient by itself: if we want to go down that path we also need to add `#[inline]`'s to the default implementations for functions like `write_all()` in the `Write` trait and so on, or implement them separately in the `Cursor` impls. But I figured I'd start a conversation about what tradeoffs we're expecting here.
Rollup of 5 pull requests Successful merges: - #60601 (Add a `cast` method to raw pointers.) - #60638 (pin: make the to-module link more visible) - #60647 (cleanup: Remove `DefIndexAddressSpace`) - #60656 (Inline some Cursor calls for slices) - #60657 (Stabilize and re-export core::array in std) Failed merges: r? @ghost
Thanks! I reviewed the rest of the slice cursor API and it looks like it all optimizes fine actually with this change due to how it's written as generic implementations. So unless I find something else we're done re: slices.
|
(Partially) brings back #33921
I've noticed in some serialization code I was writing that writes to slices produce much, much, worse code than you'd expect even with optimizations turned on. For example, you'd expect something like this to be zero cost:
...but it compiles down to dozens of instructions because the
slice_write()
calls aren't inlined, which in turn meansunwrap()
can't be optimized away, and so on.To be clear, this pull-req isn't sufficient by itself: if we want to go down that path we also need to add
#[inline]
's to the default implementations for functions likewrite_all()
in theWrite
trait and so on, or implement them separately in theCursor
impls. But I figured I'd start a conversation about what tradeoffs we're expecting here.