We went form "Go is 50x more lines of code than C#" to "C# code is not that bigger than Go". The OP was dramatically wrong about Go being more verbose than C# when the exact opposite is true.
My point is that if you want to KNOW which language is faster (as opposed to trying to PROVE that YOUR language is faster) you wouldn't compare a C# code optimized with SIMD intrinsics with Go code that doesn't use SIMD intrinsics.
The problem with BenchmarksGame is that it doesn't try to enforce apples-to-apples benchmarks.
It's fun thing to see how far you can push a given implementation if you're willing to spend a lot of time on it.
It compares implementation of the benchmark code, not the quality of the compilers on the code that you'll actually write in real life.
> The OP was dramatically wrong about Go being more verbose than C# when the exact opposite is true.
Sorry, I missed the proof - can you point me to it?
What you presented as "more verbose code" isn't actually a proof - i.e. yes, SIMD code is obviously more verbose than a normal one. And faster.
> Go has support for assembly and supports SIMD intrinsics just fine.
But wait, in this sense any language has support for assembly and SIMD. Bundled assembler is not the same as language-level support for SIMD - and even in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... a large portion of SIMD code is actually cross-platform (what uses Vector<double>), and I am pretty sure sticking to just cross-platform SIMD APIs would be enough to beat Go.
> You wouldn't compare a C# code optimized with SIMD intrinsics with Go code that doesn't use SIMD intrinsics.
You use what's not against the rules, and it's not against the rules on CLBG. You're free to submit your own version of the same benchmark on Go relying on SIMD or whatever you prefer.
> It compares implementation of the benchmark code, not the quality of the compilers on the code that you'll actually write in real life.
Yes, any benchmark is somewhat biased. But honestly, comparing real-life benchmarks is even harder - they involve much more components, so whoever isn't happy with the results can always claim it's a comparison of frameworks, not the actual programs, etc., etc.
Go has support for assembly and supports SIMD intrinsics just fine. See for example https://github.com/bamiaux/rez/blob/master/vscalers_amd64.s
My point is that if you want to KNOW which language is faster (as opposed to trying to PROVE that YOUR language is faster) you wouldn't compare a C# code optimized with SIMD intrinsics with Go code that doesn't use SIMD intrinsics.
The problem with BenchmarksGame is that it doesn't try to enforce apples-to-apples benchmarks.
It's fun thing to see how far you can push a given implementation if you're willing to spend a lot of time on it.
It compares implementation of the benchmark code, not the quality of the compilers on the code that you'll actually write in real life.