I still feel like #[repr(C, packed)] is the way to go if you truly need layout control. Rust still reserves the right to reorder and repack struct and enum types. I'm not sure if there's a guarantee for tuple types or if they're isomorphic to a struct with integer-named members with the matching types.
repr(C, packed) isn't gonna make someone else's padding magically go away. it also doesn't work (nor is meant to work) with references to fields.
#[repr(packed)] is not what matter here, you just need to put them all in one struct. Even one tuple ((u32, u8, u16, u8)) will do. Then rustc will be free to reorder the fields to reduce space overhead, because it will not affect program behavior. In fact, it'll even do that (though nothing is guaranteed).
1 Like
Why do you want to be able to change someone else's padding without editing their code? If you need to do that, either make a pull request for improvements or consider forking the project to apply and maintain the changes yourself. Trying to decide the layout of an external crate's type without actually taking responsibility of it is bound to create problems.
That's why it should be the compiler's responsibility to take care of it.
We really do hope GCC Rust gets this feature, even if at the expense of a slightly non-compliant ptr::copy/etc. It will be okay, it shouldn't break too much.
Y'know, composable programming is a thing nowdays. You never really make your own structs, you just combine a bunch of other ppl's. But it optimizes badly. That should be fixed. Should you add generics to all your structs so that the user can bring in their own things into your padding? That could be an alternative, but it's not a nice one.
Don't hold your breath. gcc-rs is striving for full compatibility with rustc, and adding new features is a non-goal. lccc will be the same (though only compatibility with stable rustc is a goal), though adding features behind unstable feature gates that aren't in conflict with stable features is permitted.
3 Likes
This is yet another time where you should be giving concrete examples. You say that you are looking at code where the optimization you want will reduce memory consumption by 50%, that this makes the difference between fitting into RAM and not, and that it involves composing structs where you don't control all of the type definitions. OK. I'm actually willing to believe that if you show us the actual code with the problem. You might even be able to convince me that your suggested change really is the only change that will solve the problem!
But if you just keep saying "hey, (((u32, u8), u16), u8) could take less space therefore Rust must make it take less space, compatibility and type system constraints be damned," then I and everyone else here are going to write this thread off as yet another time Soni came in with an impractical proposal and wouldn't work with us to turn it into a practical one.
/frustrated
20 Likes
Alright, can we start with getting memory profilers to add a "padding-to-data ratio" to their output? Unfortunately there doesn't seem to be any tools that output this kind of information.
You can use -Z print-type-sizes to get rustc to print out information about the size of the types used in the program (including padding information). The information isn't printed in the format you want, but you should be able to make a local build of the compiler that modifies that option to print things in a different format.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.