Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/compile: type layout optimization: apply struct field reordering during compile time for efficient memory alignment #53048

Closed
Dentrax opened this issue May 24, 2022 · 3 comments

Comments

@Dentrax
Copy link

Dentrax commented May 24, 2022

Context

The goal is to divorce the order of fields in source code from the order of struct fields, then optimize structs by always ordering fields from least to most aligned in memory layout. 1

Proposal

type Unoptimized struct {
  a int8
  b int16
  c int8
  ...
}

During compile time optimization phase, Go should try to optimize reordering for all structs and their fields.

type LetGoOptimize struct {
  a int8
  b int8
  c int16
  ...
}

golang.org/x/tools already have a linter called fieldalignment that detects structs that would use less memory if their fields were sorted.

Backward Compatibility

I don't have much technical detail about the compiler to cover this section. So waiting your thoughts!

  • New go:noreorder compiler directive

The //go:noreorder directive must be followed by a type struct declaration. It specifies that auto reordering should not be applied, overriding the compiler's usual optimization rules.

Similar Works

P.S: I couldn't find neither a similar proposal her nor discussions; so feel free to close and drop some references if this is duplicate or have discussed before.

Footnotes

  1. https://go101.org/article/memory-layout.html

@gopherbot gopherbot added this to the Proposal milestone May 24, 2022
@seankhliao
Copy link
Member

Duplicate of #36606

@seankhliao seankhliao marked this as a duplicate of #36606 May 24, 2022
@AndrewWPhillips
Copy link

This is not a duplicate of #36606 as that issue does not propose any reordering of fields. (However, I have seen this issue discussed before and would be surprised if this is not a duplicate of a much earlier issue but I can't seem to find one.)

@dominikh
Copy link
Member

It's more likely a duplicate of #10014.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants