https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati...
https://www.codeproject.com/Articles/1223361/Benchmarking-NE...
https://clearlinux.org/blogs-news/performant-containerized-g...
Now go play with your facts.
https://cr.openjdk.java.net/~vlivanov/talks/2017_Vectorizati...
https://www.codeproject.com/Articles/1223361/Benchmarking-NE...
https://clearlinux.org/blogs-news/performant-containerized-g...
Now go play with your facts.
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.
Like I said, play with facts if that makes you feel good.
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.