Padding is hard

http://dave.cheney.net/2015/10/09/padding-is-hard

by spacey • 11 years ago

74 29 11 years ago

dave.cheney.net

zeveb• 11 years ago

Given how much Go already does for one—and given the static nature of Go binaries—is there any reason why the compiler shouldn't reorder structs so that they take the least space possible?

I can see that that would prevent one from reliably dumping memory to disk and then re-reading it, but It's hardly reliable to do that anyway. One should be using an encoding anyway…

gtfierro• 11 years ago

Going beyond this being a minor optimization that isn't going to matter for most people, my guess is that they probably don't reorder structs because it may not be what the programmer intended. When you start introducing mechanisms for altering how the compiler sees a certain piece of code (like a struct definition), then you also need to give the programmer a way of expressing which thing they want the compiler to do, like with __attribute__ in C. Adding that feature in a straightforward way would probably involve introducing more syntax, which Go wants to avoid.

masklinn7• 11 years ago

At the same time, getting either source-layout guarantees or a way to explicitly specify layout is necessary for some task types, to avoid false sharing for instance. Go currently does neither.

coldtea• 11 years ago

Given how much Go already does for one

How much is that? As far as modern (2000 and onwards) languages Go, Golang and the compiler are pretty barebones. The compiler especially is as basic as it gets...

IshKebab• 11 years ago

The compiler especially is as basic as it gets

Which is fantastic. Nobody likes the bazillion options GCC has.

kibwen3• 11 years ago

If you're handing off a struct to C code, the order of your fields is going to be significant. If the Go compiler began reordering struct fields as an optimization, it would need to provide some way to disable that optimization on a per-struct basis (and unless Go could automatically detect which structs are crossing an FFI boundary, this optimization would need to be opt-in rather than opt-out in order to avoid breaking existing code). As a precedent, Rust deliberately does what you describe and reserves the right to reorder struct fields (though AFAIK it's not actually exercising this right yet), and in order to manually enforce a struct's layout you must tag it with the #[repr(C)] attribute.

masklinn7• 11 years ago

Go struct memory layout is currently undefined[0], so you're already not supposed to hand structs off to C, or to memcpy it to or from the wire. Unless you're using cgo maybe, I don't know if (or that) cgo provides any guarantee.

[0] https://github.com/golang/go/issues/10014

kazinator• 11 years ago

That is what FFI is for, right? Native structures do whatever they want. When gluing to C code, you use your FFI primitives to express the interfaces; and the structures which are expressed there are made to correspond to the C layout in some way.

You generally don't want to be constraining how data structures work in a language so that they can be handed off to C code directly. (Unless perhaps you're writing a language that is nearly a C dialect or something.)

adonovan2• 11 years ago

The most compact representation is not always the most efficient. If two fields in the same struct variable are accessed by different goroutines, placing them far apart so that they reside in different cache lines may avoid a great deal of contention.

masklinn7• 11 years ago

Except technically struct memory layout is currently undefined in Go so you're relying on an implementation detail.

Someone• 11 years ago

I would guess that their stance is "If you care about that, do it yourself"

IMO, that is the right attitude, given that moving fields around may interfere with how parts of large structures map to cache lines, and that may have huge performance impacts, if some parts of a structure are rarely accessed.

Yes, the compiler could try to optimize that, too, but saying that is a hard problem is an understatement, and it needs statistics that the compiler doesn't have available. So, it definitely is unsuitable for go's goal of fast compilation.

masklinn7• 11 years ago

I would guess that their stance is "If you care about that, do it yourself"

No, struct layout is currently undefined[0] so you can't do that yourself. Any manual packing you defined today may or may not hold across platforms or future go revisions.

[0] https://github.com/golang/go/issues/10014

neilc• 11 years ago

why the compiler shouldn't reorder structs so that they take the least space possible

I think you'd get most of the benefit by writing a static analysis tool (a la "go vet") that suggests when reordering a struct's fields would reduce memory consumption.

masklinn7• 11 years ago

Except Go doesn't guarantee source-order struct layout, so that'd be a suggestion relying on implementation details (see also: relying on scheduling order of goroutines).

hoprocker• 11 years ago

Side question: who is in that animated gif about a quarter of the way down the page (fingers to temples, starbursts in background)? I see that around on dev blogs quite a bit.

akira2501• 11 years ago

https://en.wikipedia.org/wiki/Tim_and_Eric_Awesome_Show,_Gre...!

It's not for everyone.

savanaly• 11 years ago

The skit it's from: https://www.youtube.com/watch?v=2G0Q7ygC2CU

atria• 11 years ago

So there isn't any equivalent to #pragma pack in Go? I'll stick with C/C++, thanks.

ajkjk2• 11 years ago

Really, just like that? Seems irrational to discount every other argument involved in such a decision.

ajkjk2• 11 years ago

If you're like me and had no idea what

_ struct{} // to prevent unkeyed literals

means, some explanation turns up here: https://groups.google.com/forum/#!topic/golang-nuts/NSjVW82i...

nkurz• 11 years ago

The article mentions that the "Go spec says the address of a struct’s fields must be naturally aligned", and seems to take for granted that is necessary for speed. A separate question would be whether it actually helps performance.

For modern x64/x86 the answer seems be to "no": http://lemire.me/blog/2012/05/31/data-alignment-for-speed-my...

Would it make sense for the Go spec to drop the alignment requirement? I'd think that a smaller memory footprint would be the better choice, and I'd think that interoperability would be better served by allowing arbitrary alignments.

Padding is hard

Related Stories