Apples to orange comparison. Java and .NET have different goals, around 2 decades of optimization and a lot more money thrown at them.
Also, hi again pjmlp! Another Go thread, another nonconstructive Go bashing coming from you. From your other comments here I see you got pretty combative this time.
Intel doesn't directly advice for neither of the 3 methods. It simply states that handcrafting assembly code is faster which is always the case anyway.
So everybody can see how dishonest pjmlp is towards Go, here is their interpretation of Intel's conclusion:
> Intel has recently published an article on using Go, their advice? Manually use cgo or Go Assembly for the AVX.
.
.
And here is the actual Intel conclusion from the link:
> The examples show how to use Intel AVX-512 with Go to improve application performance using three different methods: direct access with Go assembly, using the Go cgo interface with intrinsics for Intel AVX-512, and via indirect access with 3rd party libraries such as Gonum.
> Each method showed that using Intel AVX-512 improved Go application performance, with shorter execution times and improved date throughput overall. Using Go assembly with direct access to the CPU instruction set was faster than indirect access using cgo or Gonum.
> Clear Linus OS makes it easy to use Intel AVX-512 in Go because Clear Linux OS provides a deeply optimized software stack, including Intel AVX-512 enabled software.
.
.
To say pjmlp's interpretation was uncharitable is an understatement.
That's understandable. There's a large cost to doing cgo calls. Not to mention you get into a weird situation where the cgo calls take too long to execute and the Go scheduler/pacer can make things even worse by suspending execution.
Please enlighten us where does Intel describe how to do auto-vectorization with Go, because writing Go Assembly, using cgo writing C intrinsics by hand, or link to a third party library hand optimized doesn't look very automatic to me.
Like I said, play with facts if that makes you feel good.
Who said it needs to support vectorization natively? It's not what Go was created for so it's fine to exist as a library or assembly code.
Go has stricter goals than Java or .NET. So comparing them favorably is like saying a Corolla sucks because it lacks features present in a heavy duty truck.
Again, Intel's article doesn't advocate for any method. It just presents results. Anyone can read the article and conclude for themselves that you're extrapolating to the worse interpretation possible as usual.
Wait until a webasm thread comes around again and you'll see a real rabbit hole of extreme conflation, false claims, bad faith arguments and willful ignoring of facts and evidence.
Also, hi again pjmlp! Another Go thread, another nonconstructive Go bashing coming from you. From your other comments here I see you got pretty combative this time.