Hacker News Reader

Comment by alexyakunin | Hacker News Reader

And speaking of unsafe code and x86-specific (i.e. non-portable) AVX2 intrinsics:

1. First, unsafe doesn't mean you shouldn't use it on .NET. It just means you need to do more checks manually.

2. A lot of things you can do in Go are unsafe in .NET terms - e.g. even slice is a leaky & unsafe abstraction: https://alexyakunin.medium.com/slice-an-extremely-leaky-abst...

3. Yes, the fact Go doesn't support SIMD intrinsics explains why it loses not only to C#, but also to C++ and Rust on math-intensive tests. But it loses to C# on other tests too - e.g.: - https://benchmarksgame-team.pages.debian.net/benchmarksgame/... - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And as you might notice, the code length doesn't differ much there.

View on HN

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.

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.

> 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.

Reply on news.ycombinator.com