Are you aware that Go has experimental support for SIMD intrinsics <https://pkg.go.dev/simd@master>? I think it is unlikely that we would change the language to provide something, that we have intrinsics for.
On Thu, 2 Jul 2026 at 00:50, Cedric BAIL <[email protected]> wrote: > With Go, we can use our multi core CPU quite effectively by using > goroutine. We tell `go` and a function and that function gets executed in > parallel. What we can’t do today is tell Go to use the full capacity of one > core by processing data in parallel using SIMD instructions. > > This is what language like Mojo ( https://mojolang.org/ ), or ISPC ( > https://ispc.github.io/ispc.html ) or CUDA, OpenCL, Vulkan and friends > provide.In the case of Go, this would enable Go to stay idiomatic, readable > and portable while still being efficient by being told this code can > process data in parallel effectively. This would speed data processing up > to 32 times for byte on modern Intel CPU. > > Go already has a logical place to add this capability. If we allow the > `go` keyword to be followed by `for` `range`, it would enable data > parallelism without breaking existing Go code and keep it logical, readable > and maintainable. This would look like this: > > ``` > > func contains(data []int32, target int32) bool { > > go for _, v := range data { > > found := v == target > > if reduce.Any(found) { > > return true > > } > > } > > return false > > } > > ``` > > This above function will be on average 8 times faster on Intel CPU with > AVX2 than this current go version: > > ``` > > func contains(data []int32, target int32) bool { > > for _, v := range data { > > if v == target { > > return true > > } > > } > > return false > > } > > ``` > > To make it easier for people to understand it in practice, I built a proof > of concept that allows you to experiment using tinygo and its playground. I > enable mostly two target wasm and avx2 which you can explore the live > result in the browser for wasm and see the generated assembly for AVX2. I > also put together a blog that goes over the result here: > https://bluebugs.github.io/blogs/spmd-results/ . The playground is here: > https://gofor-tinygo.netlify.app/ . > > The short version is that by expressing parallelism at the loop level and > in an high level form, the compiler can become quite competitive even with > intrinsic hand written assembly as the performance range between 80% to > 100% of the best hand written library, but you keep the readability and > portability of Go. The compiler doesn’t get any slower as this is > mechanical transformation in the same way as normal go code. It is robust > as a `go for` is always able to become SIMD code. > > Cedric > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/b211707e-92eb-4c24-bc5a-a941940ab0b0n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/b211707e-92eb-4c24-bc5a-a941940ab0b0n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHr9EGDtxrQzw_SN1JEQumLQKXcYQphyQFuXSpgsRxpkQ%40mail.gmail.com.
