Hacker News Reader

Comment by grep_it | Hacker News Reader

This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example:

  type Wasteful struct {
    a int16
    b int
    c byte
  }

  type Aligned struct {
    b int
    a int16
    c byte
  }

Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.

View on HN

Rust does that automatically unless you switch to the C layout.

In langages that don’t there’s a tension between memory use and human readability / consistency of the layout.

There are also other domains which can be affected e.g. databases, it’s a concern / issue when using postgres for instance as it uses aligned columns and stores them in schema order.

Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.

There is no way in C to express that you don't care about the orde. When you express a struct in C, you list what you want in the struct and (sometimes without wanting it) exactly in what order you want it.

Interestingly, there is also no way to write a loop on i for all the values between 0 and 99 without specifying the order. Luckily, in this case, the compiler is allowed to prove that the order has no impact (because it's local), and to decide that it will scan the values in a different order for optimisation purposes.

So the compiler could do it on a structure as well, as soon as it's able to prove that the structure is not exposed in any way to any code that it doesn't control, but that's much more difficult than proving that variable i is not visible outside of a tight loop.

It could be a new keyword rather than counting on the compiler to prove certain access patterns don't exist. That's a bit of a messy tradeoff. Maybe something like 'unordered struct' or 'packed struct' works, but it would be a nonstandard extension for some time.

Sibling comment touched on it, and I guess rust does offer just that, but void casting and doing explicit offset checks for a field is one reason. You can kind of think of it like a tuple in that way and a db engine might use a similar technique.

It is not very hard, but it is additional complexity, and it then requires the language to have a way to opt out so you can handle things like FFI or explicit ordering (usually for padding to avoid false sharing and friends).

So most languages opt to follow what their predecessors did: do nothing and task developers with reordering the structure if they want to minimise its size.

Reply on news.ycombinator.com