4 ms·

Why not just offer the option to have manual control? That's what Rust does; by default rustc reorders fields, but you can also manually annotate your struct wi

Why not just offer the option to have manual control? That's what Rust does; by default rustc reorders fields, but you can also manually annotate your struct with #[repr(C)], which enforces no reordering.

roca 5y ago
Yeah. Automatically optimizing for space gives good cache footprint if you don't know anything about access patterns so it might as well be the default. Also, with generics, there are cases where the optimal field ordering depends on the generic type parameters, so letting the compiler reorder fields on a per-generic-instance basis gives better space utilization than any given source field ordering.
WatchDog 5y ago
Such a feature would probably require golang to either implement annotations or a new keyword. I'm not sure golang doesn't have annotations, but probably for the same reasons it's taken so long to implement generics, it's a language stuck in the 70's, with a user base and leadership that will fight tooth and nail to try and stay that way.
- Kon-Peki 5y ago
  Go most definitely allows annotations on structure fields [1]. You say the language is stuck in the 70s, but the GP has a quote from the Go authors saying that having the compiler reorder structure fields is a 1970s problem... Well anyway, mostly it just sounds like the typical Rust enthusiast "How dare you have a strongly-held opinion that differs from my strongly-held opinion". As someone who used to work on a codebase that had to be portable across X86, Alpha, SPARC, and Itanium, paying attention to structure field order quickly becomes a routine matter. It hardly seems worthy of an argument over the merits of a programming language. [1] https://pkg.go.dev/reflect#StructTag https://pkg.go.dev/reflect#StructTag
  - adwn 5y ago
    > Well anyway, mostly it just sounds like the typical Rust enthusiast "How dare you have a strongly-held opinion that differs from my strongly-held opinion" To the contrary, it sounds like "Here's a solution that gives better results in 99% of cases, for reasons X, Y, Z, and better control and guarantees in those other 1% of cases."
  - Ar-Curunir 5y ago
    No need to be defensive, I was merely suggesting one approach, and didn't even criticize Go anywhere in my comment.
  - rsecora 5y ago
    Its not really a 70s problem, its a solution to a problem if the 1970s. RISC machines raised bus error if not properly aligned to avoid "double" access to the same value. https://en.wikipedia.org/wiki/Bus_error#Unaligned_access https://en.wikipedia.org/wiki/Bus_error#Unaligned_access
- masklinn 5y ago
  > I'm not sure golang doesn't have annotations It does, the `//go:` stricture is a pragma / annotation. And though I don’t remember any being at the struct-definition level, Go 1.16 added one at the “const” (toplevel var) level so adding it for structs doesn’t seem like an issue.
- geodel 5y ago
  > with a user base and leadership that will fight tooth and nail to try and stay that way. This is hilarious. If majority users and authors of language all like same thing then for whom this problem is to be fixed in general? Is it for non-users of Go?
jerf 5y ago
Because in practice the Go solution is the other way around: You can optionally decide to worry about it by turning on the linter that detects this. It's not a very different solution in practice. I actually kind of like the idea of a minimal language with a robust linting/static analysis community. You can modularly pick what things you want to worry about. The correct answer for the vast bulk of Go programmers is not to worry about this, and the ones who want to, the tools are readily available and already integrated into a tool that anyone writing serious Go code should already be using.
- kibwen 5y ago
  > It's not a very different solution in practice. It makes a difference in the presence of generics, since at that point laying out fields efficiently in the face of every possible combination of types is a task that only the compiler can perform. There's nothing that says that it needs to be the default behavior, but if you want efficient space usage then you need more than a lint, you need some way to enable automatic field reordering.
  - jerf 5y ago
    Fair enough, I don't think of generics as quite existing yet so I haven't started considering them yet. I suspect in practice we're not going to see a lot of structs with a bajillion generics in them, though. Generics are going to solve the problems the Go developers said they will solve but there's still just enough friction in them (particularly the inability to introduce new types in methods) that I expect it will not be practical to create C++-like libraries of generic things that take generics that take generics as arguments, and in practice, "stick the small number of generic things (most likely one) at the end of the struct" will mostly cover the bases. (I have no problem saying that if you need the n'th degree in performance, you shouldn't have picked Go. I think it has a great bang-for-the-buck ratio, but it definitely does not occupy the "best possible performance" slot.)
    - kibwen 5y ago
      > I suspect in practice we're not going to see a lot of structs with a bajillion generics in them Sure, but note that it only takes a single generic parameter to exhibit this behavior. Consider the original struct definition in the OP: if we imagine that the first field was generic instead of uint8, then the struct has padding only when the type is less than 16 bits in size. No matter where you manually reorder that field, some possible types will still result in padding if the fields are forced to be laid out in order, and it took no more than a single type parameter.

roca 5y ago

Yeah. Automatically optimizing for space gives good cache footprint if you don't know anything about access patterns so it might as well be the default. Also, with generics, there are cases where the optimal field ordering depends on the generic type parameters, so letting the compiler reorder fields on a per-generic-instance basis gives better space utilization than any given source field ordering.

WatchDog 5y ago

Such a feature would probably require golang to either implement annotations or a new keyword. I'm not sure golang doesn't have annotations, but probably for the same reasons it's taken so long to implement generics, it's a language stuck in the 70's, with a user base and leadership that will fight tooth and nail to try and stay that way.

Kon-Peki 5y ago
Go most definitely allows annotations on structure fields [1]. You say the language is stuck in the 70s, but the GP has a quote from the Go authors saying that having the compiler reorder structure fields is a 1970s problem... Well anyway, mostly it just sounds like the typical Rust enthusiast "How dare you have a strongly-held opinion that differs from my strongly-held opinion". As someone who used to work on a codebase that had to be portable across X86, Alpha, SPARC, and Itanium, paying attention to structure field order quickly becomes a routine matter. It hardly seems worthy of an argument over the merits of a programming language. [1] https://pkg.go.dev/reflect#StructTag https://pkg.go.dev/reflect#StructTag
- adwn 5y ago
  > Well anyway, mostly it just sounds like the typical Rust enthusiast "How dare you have a strongly-held opinion that differs from my strongly-held opinion" To the contrary, it sounds like "Here's a solution that gives better results in 99% of cases, for reasons X, Y, Z, and better control and guarantees in those other 1% of cases."
- Ar-Curunir 5y ago
  No need to be defensive, I was merely suggesting one approach, and didn't even criticize Go anywhere in my comment.
- rsecora 5y ago
  Its not really a 70s problem, its a solution to a problem if the 1970s. RISC machines raised bus error if not properly aligned to avoid "double" access to the same value. https://en.wikipedia.org/wiki/Bus_error#Unaligned_access https://en.wikipedia.org/wiki/Bus_error#Unaligned_access
masklinn 5y ago
> I'm not sure golang doesn't have annotations It does, the `//go:` stricture is a pragma / annotation. And though I don’t remember any being at the struct-definition level, Go 1.16 added one at the “const” (toplevel var) level so adding it for structs doesn’t seem like an issue.
geodel 5y ago
> with a user base and leadership that will fight tooth and nail to try and stay that way. This is hilarious. If majority users and authors of language all like same thing then for whom this problem is to be fixed in general? Is it for non-users of Go?

jerf 5y ago

Because in practice the Go solution is the other way around: You can optionally decide to worry about it by turning on the linter that detects this. It's not a very different solution in practice. I actually kind of like the idea of a minimal language with a robust linting/static analysis community. You can modularly pick what things you want to worry about. The correct answer for the vast bulk of Go programmers is not to worry about this, and the ones who want to, the tools are readily available and already integrated into a tool that anyone writing serious Go code should already be using.

kibwen 5y ago
> It's not a very different solution in practice. It makes a difference in the presence of generics, since at that point laying out fields efficiently in the face of every possible combination of types is a task that only the compiler can perform. There's nothing that says that it needs to be the default behavior, but if you want efficient space usage then you need more than a lint, you need some way to enable automatic field reordering.
- jerf 5y ago
  Fair enough, I don't think of generics as quite existing yet so I haven't started considering them yet. I suspect in practice we're not going to see a lot of structs with a bajillion generics in them, though. Generics are going to solve the problems the Go developers said they will solve but there's still just enough friction in them (particularly the inability to introduce new types in methods) that I expect it will not be practical to create C++-like libraries of generic things that take generics that take generics as arguments, and in practice, "stick the small number of generic things (most likely one) at the end of the struct" will mostly cover the bases. (I have no problem saying that if you need the n'th degree in performance, you shouldn't have picked Go. I think it has a great bang-for-the-buck ratio, but it definitely does not occupy the "best possible performance" slot.)
  - kibwen 5y ago
    > I suspect in practice we're not going to see a lot of structs with a bajillion generics in them Sure, but note that it only takes a single generic parameter to exhibit this behavior. Consider the original struct definition in the OP: if we imagine that the first field was generic instead of uint8, then the struct has padding only when the type is less than 16 bits in size. No matter where you manually reorder that field, some possible types will still result in padding if the fields are forced to be laid out in order, and it took no more than a single type parameter.