6 ms·

Rust does structure packing automatically. This is great for the general programmer (someone who is not knowledgeable or caring about details like this.) Unfo

by devbug 12y ago

Rust does structure packing automatically. This is great for the general programmer (someone who is not knowledgeable or caring about details like this.) Unfortunately, this blows for people who do (someone like me.)

grok2 12y ago
Is there a way to request that the compiler not do this on a per-structure basis?
- dezgeg 12y ago
  There's a #[repr(C)] annotation that can be placed on a struct, IIRC.
  - FreeFull 12y ago
    That guarantees the same layout that C would have for that struct. There is also #[repr(packed)] which puts things as close as possible without alignment, and then you can insert padding manually with fields of type [u8; N] where N is the number of bytes.
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
Ded7xSEoPKYNsDd 12y ago
Why does it blow for you? If the compiler can do it automatically, that seems very useful. Or is it doing it suboptimally? (Say you want two fields in the same cache line, but the compiler sorts them away.)
- devbug 12y ago
  I know better than the compiler how my data is used. It is really simple as that. I can optimize with the totality of the program in mind while the compiler optimizes on heuristic like `order largest to smallest`. So yes, the compiler is doing it sub-optimally. Not to mention the repetitious hell it creates when writing C bindings, or memory-mapping structures, and so on and so forth. In the end, however, my reservations are mostly due to a "get off my lawn" mentality.
  - spiritplumber 12y ago
    Are you Mel Kaye?
    - devbug 12y ago
      Hah! Only when the difference in performance is end-user discernible. I do make sure the code is well crafted in those bounds though. There's no _valid_ excuse for crafting ugly code. Coincidently my stuffed toy that I have kept throughout my childhood was named "Mel the Pal." I just noticed the irony of that. :)
- banachtarski 12y ago
  The compiler can't know exactly how I intend the data to be read or written to at runtime. You generally don't want to read and write to the same cache line at a time.
andreasvc 12y ago
This comment claims the opposite: https://news.ycombinator.com/item?id=9069489 https://news.ycombinator.com/item?id=9069489
dbaupp 12y ago
The field order of structs is unspecified by default, to allow, e.g. reordering to the smallest size, or even randomising for security/fuzz testing. One can opt-in to a fixed in-order layout with `#[repr(C)]` and even avoid padding for such a struct with `#[repr(C, packed)]`. NB. in general it is impossible to pack a struct perfectly manually, e.g. generic structs can have their order for minimal size change depending on what types they're used with. It can even be somewhat platform specific, with e.g. pointers changing size/alignment on 32-bit vs. 64-bit computers (although pointers probably aren't problematic, since they're switching between two adjacent classes).

by devbug 12y ago

grok2 12y ago

Is there a way to request that the compiler not do this on a per-structure basis?

dezgeg 12y ago
There's a #[repr(C)] annotation that can be placed on a struct, IIRC.
- FreeFull 12y ago
  That guarantees the same layout that C would have for that struct. There is also #[repr(packed)] which puts things as close as possible without alignment, and then you can insert padding manually with fields of type [u8; N] where N is the number of bytes.
deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

Ded7xSEoPKYNsDd 12y ago

Why does it blow for you? If the compiler can do it automatically, that seems very useful. Or is it doing it suboptimally? (Say you want two fields in the same cache line, but the compiler sorts them away.)

devbug 12y ago
I know better than the compiler how my data is used. It is really simple as that. I can optimize with the totality of the program in mind while the compiler optimizes on heuristic like `order largest to smallest`. So yes, the compiler is doing it sub-optimally. Not to mention the repetitious hell it creates when writing C bindings, or memory-mapping structures, and so on and so forth. In the end, however, my reservations are mostly due to a "get off my lawn" mentality.
- spiritplumber 12y ago
  Are you Mel Kaye?
  - devbug 12y ago
    Hah! Only when the difference in performance is end-user discernible. I do make sure the code is well crafted in those bounds though. There's no _valid_ excuse for crafting ugly code. Coincidently my stuffed toy that I have kept throughout my childhood was named "Mel the Pal." I just noticed the irony of that. :)
banachtarski 12y ago
The compiler can't know exactly how I intend the data to be read or written to at runtime. You generally don't want to read and write to the same cache line at a time.

andreasvc 12y ago

This comment claims the opposite: https://news.ycombinator.com/item?id=9069489 https://news.ycombinator.com/item?id=9069489

dbaupp 12y ago

The field order of structs is unspecified by default, to allow, e.g. reordering to the smallest size, or even randomising for security/fuzz testing. One can opt-in to a fixed in-order layout with `#[repr(C)]` and even avoid padding for such a struct with `#[repr(C, packed)]`. NB. in general it is impossible to pack a struct perfectly manually, e.g. generic structs can have their order for minimal size change depending on what types they're used with. It can even be somewhat platform specific, with e.g. pointers changing size/alignment on 32-bit vs. 64-bit computers (although pointers probably aren't problematic, since they're switching between two adjacent classes).