I prefer C#. But here the Go code actually looks like normal production code while the C# examples look like something made by a low-level optimization wizard.
I looked at the k-nucleotide, n-body, etc and saw nothing out of the ordinary in terms of C#.
There wasn’t even a lot of “modern C#” low level optimization like ref-structs/spans and similar. It actually looks like there is quite a bit of performance from C#8, 9, 10 left on the table.
// prevent inlining into main to decrease JIT time to generate main
[SkipLocalsInit][MethodImpl(NoInlining)]
[SkipLocalsInit][StructLayout(LayoutKind.Explicit, Pack = 32)]
[SkipLocalsInit][MethodImpl(AggressiveOptimization | NoInlining)]
[FieldOffset(32)]
and tons of "unchecked" blocks.
Not to mention that the entire file is using explicit vectorization, which I consider to be a very high degree of optimization -- tons of software never bothers to implement explicit vectorization, and does just fine.
If all of this is "nothing out of the ordinary", then "ordinary" C# has changed a lot since I last spent much time with it.
Agree - those attributes are definitely “low level” and not idiomatic in most situations. I must have missed them skimming that file.
For the particular case of n-body you could argue you are already in a pretty extreme HPC world and doing it without vectors would basically be a toy calculator. The problem then of course that C# isn’t really ever idiomatic for that. The question (as alaways) becomes about what to compare. Typical or pushed to the limit.
If what's in the Benchmarks Game is normal Go code to you, then I feel pretty bad for you in terms of what your colleagues are exposing you to on a day-to-day basis quality-wise.
