Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lost Art of C Structure Packing (2014)

catb.org

Post reply on HN
Print view View original

41–50 of 116 posts

Re: The Lost Art of C Structure Packing (2014)

#41

Post by dysoco »

kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

Alright this might be a stupid question, but if packing is about the order in which the fields are arranged... shouldn't the compiler optimize that? I mean, it does much more complex optimizations already doesn't it?

Re: The Lost Art of C Structure Packing (2014)

#42

Post by Arnavion »

dysoco wrote: post #41
kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

Alright this might be a stupid question, but if packing is about the order in which the fields are arranged... shouldn't the compiler optimize that? I mean, it does much more complex optimizations already doesn't it?

The language spec prevents it from doing so for ABI reasons.

The optimization is present in other languages that did not start with this restriction, but it's too late for C now.

Re: The Lost Art of C Structure Packing (2014)

#43

Post by cdavid »

dysoco wrote: post #41
kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

Alright this might be a stupid question, but if packing is about the order in which the fields are arranged... shouldn't the compiler optimize that? I mean, it does much more complex optimizations already doesn't it?

The compiler can't optimize this in general as this affects the ABI when the struct itself is exposed (that's one of the reason why it is useful to avoid exposing struct themselves but just pointer when you can).

Re: The Lost Art of C Structure Packing (2014)

#44

Post by dalailambda »

dysoco wrote: post #41
kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

Alright this might be a stupid question, but if packing is about the order in which the fields are arranged... shouldn't the compiler optimize that? I mean, it does much more complex optimizations already doesn't it?

A lot of systems code involves directly messing with the memory of a specific struct, and if a compiler moved the struct fields around with the programmer knowing, there would be a lot of memory problems.

Re: The Lost Art of C Structure Packing (2014)

#45

Post by throwanem »

kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

> reverse descending order

...so, ascending order?

Re: The Lost Art of C Structure Packing (2014)

#46

Post by mikeash »

minipci1321 wrote: post #5

Sigh... apparently this is now enough of rocket science to be considered for posting on HN... People using packing pragma of GCC should also beware -- an access to a field of a packed structure will be done bytewise, whether a variable happens to be actually aligned or not (I guess the compiler simplified its life by assuming no variable is ever aligned in packet structs), so memory size would go down but CPU use mig…

I would guess that if the struct is packed, the compiler won't assume any particular alignment for the struct itself either, so even if a member is properly aligned relative to the beginning of the struct, it may not be properly aligned in memory.

Re: The Lost Art of C Structure Packing (2014)

#47

Post by andrepd »

qwertyuiop924 wrote: post #36

ESR is a good programmer, and this is a handy guide for those who don't know how to pack structures. He's also insane, so don't trust anything he says. Oh, you don't think he's insane? He thinks there's a conspiracy amongst women in open source to discredit Linus Torvalds. No, I'm not joking. I wish I was.

Offtopic. His opinions on open source politics are little matter to his technical insights. I can appreciate Hitler's paintings, etc etc.

Re: The Lost Art of C Structure Packing (2014)

#48

Post by Crespyl »

ThatGeoGuy wrote: post #40

Although I somewhat tire of constant comparisons between Rust and C, in this case it's interesting so I'll ask: Does Rust do struct packing any differently than C and what kinds of tradeoffs are associated with that? Most people don't even think about struct packing in the context of C++ (which is in many ways closer to Rust) because of vtables / inheritance / etc, but in this case I'd like to know if Rust does anyth…

IIRC, Rust struct layout is undefined/unstable, unless you explicitly use the #repr(C) tag on the struct definition, in which case it behaves pretty much exactly like C. You can also specify that the struct be packed, with no padding between items if necessary.

I'm not sure if unmarked Rust structs actually get layout optimized or not right now, but they've worked to keep that option available.

Re: The Lost Art of C Structure Packing (2014)

#49

Post by Grishnakh »

kazinator wrote: post #31

TL;DR: to get smaller structures, don't do stuff like this: struct foo { char a; int b; char c; int d; }; but this: struct foo { int b; // or int b, c; int c; char a; char c; }; Basically if you sort the types by size in reverse descending order, you get optimal packing without messing with compiler-specific packing extensions that skew alignment and possibly bloat code. The worst that you will get is padding at the…

Wouldn't it make sense for the compiler to automatically optimize stuff like this? The compiler knows all about the underlying architecture the code will be running on, so it's best positioned to determine how to order data for optimal efficiency.
Post reply on HN