On Sun, Sep 13, 2020 at 1:50 AM josvazg <josv...@gmail.com> wrote: > > This is not a proposal, just a curiosity question to check if anyone in the > Go ecosystem has already thought on this issue and have some solutions in > mind. > > I might be late to this realization, but nowadays is pretty clear Intel > monolithic ISA dominance is threatened. ARM is taking over Macs and Amazon is > doubling their offer of ARM based Cloud instances. In the end, you can't > ignore chips with comparable performance but lower power consumption and heat > dissipation issues. > > This is not yet disruptive for Go. Go already produces ARM binaries, so I'd > expect it might just mean more compilations to ARM will happen and be > offered. Maybe also ARM optimizations might see higher demand. > > RISCV is a different story. > > If server/laptop grade RISCV SoCs achieve a similar performance/power > consumption ratio to their ARM counterparts, as they have no licensing costs > & are extensible, I expect they are going to spread very quickly. ARM > already saw this recently and is opening up a few of their licenses. > > And RISCV is not like the others for Go. RISCV is a modular extensible ISA, > including standard and custom extensions. > > The standard extensions may already require some compiler architecture > rework. Go might chose not to do anything and just support a handful of the > most common RISCV ISA combinations... or add ISA modularity support. Starting > from the mandatory core ISA, prefer specific module instructions to generic > ones when the module letters are present in the GOARCH=riscvxxx passed in. > > The custom extensions may be even more disruptive. Go could chose to ignore > them altogether so that Go compiled programs are always generic and can never > use the custom extensions. But if RISCV takes off, that would mean Go > programs will be slower and not really suitable for custom workloads some > companies may have preferred to run on Go on their chosen chipset. > > On way around could be to provide compiler plugins so that some Go end users > can extend the go compiler to use the custom extensions where they make > sense. So they can customize their Go binaries for their workloads as they > see fit. I expect having a plugin like this that has a simple & usable API to > be tricky, to say the least. But I am not an expert so I might be wrong. > > Another way could be to provide even more generic compilations, and leave the > final custom compilation step to the targets. > > For instance, the Go way could advise to just compile to GOARCH=wasm and > leave the optimizations to a custom WASM runtime available at the target. > That runtime is extended from the generic RISCV WASM runtime to use that > particular chipset custom ISA extensions when appropriate. But Go is not > involved in any way on that runtime, it might be even written in Rust or > something else or be a Go program not provided as part of the Go language or > tooling. > > Or Go could chose to ship unfinished compilations for this, not unlike JVM > bytecodes. It could still be WASM or maybe the intermediate SSA > representation of the program, and then provide an extensible transpiler that > Go developers using particular custom ISA extensions can extend and use to > produce the final custom static binary. It might be even embedded into the > go tool so that when you "go get" you already get the custom executable > locally. That would be very cool, but probably as tricky as the compiler > plugins mentioned above. In fact, this and the compiler plugins option might > end up being the same. > > I'd expect Go will not evolve to provide an extensible VM runner or JIT > compiler environment. It seems too far a departure from the go runtime model > and also will bring many known nuisances that plague these systems like JVM > (big runtime env needed in the target, higher memory consumption, etc) > > So just curiosity, has any one have a thought on this or can point to > literature on this matter?
The way we've historically approached this kind of thing is to use a fixed GOARCH value and to use a separate environment variable, which for RISCV would be GORISCV and, perhaps, GORISCV64. That separate environment variable would be the set of specific architecture variants that matter. For example, see the variables GOARM, GO386, etc., at https://golang.org/cmd/go/#hdr-Environment_variables . Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUZ3VCiJwp1WpMCZ-rq4OMdxwSYx-xH_BKr0EX01SXDLw%40mail.gmail.com.
