Track amd64 variants

[jonjohnsonjr]

Context: golang/go#45453

I'm not sure how much we want to track go's compiler support for various platforms, but given that we already kind of do, I'm opening this issue to start a discussion because the go proposal is likely accept, and variant says:

When the variant of the CPU is not listed in the table, values are implementation-defined and SHOULD be submitted to this specification for standardization.

[jonjohnsonjr]

The golang proposal has been accepted.

[jonboulle]

Nice catch - I think it makes sense to add the micro-architectures as variants, just a few new table entries there (though, to be pedantic, not so much because I want to track the go compiler but rather because it is an upstream agreement among the vendors).

I'm somewhat indifferent on the baseline vs. "v1" debate..

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex

[jonjohnsonjr]

I'm somewhat indifferent on the baseline vs. "v1" debate..

I tend to agree, but having everything be v<integer> is nicer aesthetically :P

[imjasonh]

FYI the above accepted proposal is slated to be included in the upcoming Go 1.18: https://tip.golang.org/doc/go1.18#amd64

[rhatdan]

Did this make it into go 1.18? Should this be merged?

[sudo-bmitch]

I'm seeing it in 1.18:

$ docker run --rm golang:1.18.5 go env GOAMD64
v1

This is only an issue, but I'd be open to a PR. We just need to be sure that adding this doesn't break existing implementations.

[zeronewb]

It would be really nice to have labeling options for uarch ; use case: heterogeneous compute clusters, with mixed hardware ( zen2, zen3, haswell, skylake, etc )
Unfortunately, GOAMD64 not covering this instruction sets hell.

[ziggythehamster]

It appears that containerd now supports amd64 variants, so I figured I'd link that PR and bump discussion here since I don't know what the greater ecosystem support is at the moment.

[tianon]

golang/go#61476 (comment) is also very recent and related (but for riscv64)

Personally, I agree we should document this and that we should follow Go and containerd's lead (v1, v2, etc).

[ziggythehamster]

The RISC-V architecture variant names have a very bad mouthfeel :). Wrong issue for this discussion, but linux/riscv64/rva23u is probably what I would do rather than footgun myself by assuming I can make the variant a number prefixed with “v”. Or potentially linux/riscv64/a20s (in the 32-bit case, drop 64). Definitely not foo/v20 or foo/v23 though like it is with arm and x86_64.

[tianon]

Doh yes, sorry, those were two separate thoughts that I didn't actually separate well -- I meant I'm +1 on v1, v2, etc for amd64 and separately that riscv64 variants are a thing we should be looking at / thinking about too. 😅

[tianon]

More: we should probably also document power8 etc for at least ppc64le (not sure if there are other POWER platforms worth documenting that for); maybe also microarchitecture levels for System Z/s390x?

https://github.com/golang/go/blob/e85968670e35fc24987944c56277d80d7884e9cc/src/cmd/dist/build.go#L145-L185
https://github.com/golang/go/blob/e85968670e35fc24987944c56277d80d7884e9cc/src/internal/buildcfg/cfg.go#L58-L175

The risk for s390x is that there isn't a GOS390 or GOS390X variable (yet?) so if we document something it might be conflicting.

We got almost that with golang/go#60905, where GOARM64 is being added, but with explicit v8.0, v8.1, etc and no support for a bare v8 at this time (which I think is fine, since it's pretty unambiguous in our case that v8 is v8.0, but that also means implementations currently parsing variant on arm64 should get ready to support a minor version too).