4 ms·

C# is blessed on that front. Java’s SIMD state is still sad, and golang is not as great either.

ashf023 1y ago
Yeah, golang is a particular nightmare for SIMD. You have to write plan 9 assembly, look up what they renamed every instruction to, and then sometimes find that the compiler doesn't actually support that instruction, even though it's part of an ISA they broadly support. Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. So without compiler support I don't believe there's any way to do something like intrinsics even. Fortunately compiler support for intrinsics seems to be on its way! https://github.com/golang/go/issues/73787 https://github.com/golang/go/issues/73787
- Thaxll 1y ago
  Go has been using register based calling for a while now?
  - immibis 1y ago
    GP comment said it's not used for FFI, not that it's not used.
    - kbolino 1y ago
      You're both stating things that are a bit beside the point. Pure Go code uses registers to pass function arguments whenever possible. Large structs and/or numerous arguments can still spill onto the stack, though. FFI (cgo) uses whatever the platform's calling convention requires. These conventions also usually favor registers. Go has its own assembly language, which is neither of those two things. Go assembly technically supports two ABIs, one called "ABI0" and the other called "ABIInternal" [1]. The former passes all arguments on the stack and is stable while the latter passes some arguments through registers but is unstable and subject to change. Accordingly, people writing Go code outside of the Go toolchain almost always use ABI0, so that the code keeps working even when new versions of Go are released. [1]: https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/cmd/compile/internal-abi.md https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/c...
- kbolino 1y ago
  > Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. Even if you had access to the register convention (which you kind of do), would it be of any benefit? The registers in question are general-purpose registers, not vector registers.
soupy-soup 1y ago
To be fair, Java's lack of support seems to have more to do with them needing to fix the whole primitive vs object mess rather than a lack of effort. It sounds like the Vector API will be stabilized shortly after they figure that out, but who knows how long it will take.
pjmlp 1y ago
While it is blocked on Valhala, it is quite usable, if folks use nightly all the the time with Rust, what is the problem with --preview?

Yeah, golang is a particular nightmare for SIMD. You have to write plan 9 assembly, look up what they renamed every instruction to, and then sometimes find that the compiler doesn't actually support that instruction, even though it's part of an ISA they broadly support. Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. So without compiler support I don't believe there's any way to do something like intrinsics even. Fortunately compiler support for intrinsics seems to be on its way! https://github.com/golang/go/issues/73787 https://github.com/golang/go/issues/73787

Thaxll 1y ago
Go has been using register based calling for a while now?
- immibis 1y ago
  GP comment said it's not used for FFI, not that it's not used.
  - kbolino 1y ago
    You're both stating things that are a bit beside the point. Pure Go code uses registers to pass function arguments whenever possible. Large structs and/or numerous arguments can still spill onto the stack, though. FFI (cgo) uses whatever the platform's calling convention requires. These conventions also usually favor registers. Go has its own assembly language, which is neither of those two things. Go assembly technically supports two ABIs, one called "ABI0" and the other called "ABIInternal" [1]. The former passes all arguments on the stack and is stable while the latter passes some arguments through registers but is unstable and subject to change. Accordingly, people writing Go code outside of the Go toolchain almost always use ABI0, so that the code keeps working even when new versions of Go are released. [1]: https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/cmd/compile/internal-abi.md https://go.googlesource.com/go/+/refs/heads/dev.regabi/src/c...
kbolino 1y ago
> Go assembly functions are also not allowed to use the register-based calling convention, so all arguments are passed on the stack, and the compiler will never inline it. Even if you had access to the register convention (which you kind of do), would it be of any benefit? The registers in question are general-purpose registers, not vector registers.

soupy-soup 1y ago

To be fair, Java's lack of support seems to have more to do with them needing to fix the whole primitive vs object mess rather than a lack of effort. It sounds like the Vector API will be stabilized shortly after they figure that out, but who knows how long it will take.

pjmlp 1y ago

While it is blocked on Valhala, it is quite usable, if folks use nightly all the the time with Rust, what is the problem with --preview?