As a first step, it might be possible to write a linter rule that rewrites suitable numeric loops to SIMD. There are already rules to rewrite several loop types, so that should be doable.
It's hard to make predictions with an open source project, but my personal guess is some flavor of it will land (including it is already demonstrating good results without an enormous level of code complexity in the compiler and without overly slowing down compile speeds), but I guess we'll see.
It's being driven by an external contributor who has landed some good changes in the past to the Go compiler. (I think the autovectorization work might be part of their PhD or other academic research, but not sure.)
physicsguy · · focus · HN ↗
The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.
tgv · · focus · HN ↗
pjmlp · · focus · HN ↗
While reaching out to CGO is the easier way, it doesn't mean it is the only tool available in Go.
typical182 · · focus · HN ↗
There's a CL stack here:
<a href="https://go.dev/cl/791740" rel="nofollow">https://go.dev/cl/791740
It's hard to make predictions with an open source project, but my personal guess is some flavor of it will land (including it is already demonstrating good results without an enormous level of code complexity in the compiler and without overly slowing down compile speeds), but I guess we'll see.
It's being driven by an external contributor who has landed some good changes in the past to the Go compiler. (I think the autovectorization work might be part of their PhD or other academic research, but not sure.)