|
|
|
|
|
|
by pjmlp
6 days ago
|
|
|
Basically a political answer that answers nothing. It isn't performance compiling, as that is only surprising for those that never used 90's compiled languages like Modula-2, Object Pascal, Clipper and co. It isn't performance of code execution, as even GCCGO could beat the reference implementation, unfortunately now stagnant since no one cares to update it beyond Go 1.18. And to go back to the article, as pointed out there, > The Go toolchain does not currently generate any AVX512 instructions. Thus leaving performance on the table. |
|
|
This just misunderstands the documentation. Compilers do not generally emit much of any AVX512, and the docs are just stating that the Go toolchain itself never emits it at the current time.
Use of AVX512 instead usually comes from explicit intrinsics or handwritten assembly in the compilers you're thinking of, and it is the same in Go. There isn't much AVX512 code in the standard library, but it is there and the GOAMD64=v4 flag means that it does not have to use runtime CPUID feature detection.
External Go libraries like simdjson-go also actively use AVX512. AVX512 does nothing for code not written with SIMD in mind anyway.