3 ms·
Because there are lies, damn lies and benchmarks. I looked at first benchmark (funkuch-redux) where C# significantly beats Go (8.3 vs 32). It turns out that t
by kjksf 4y ago
Because there are lies, damn lies and benchmarks.
I looked at first benchmark (funkuch-redux) where C# significantly beats Go (8.3 vs 32).
It turns out that the winning C# programs uses SSE2 intrinsics.
The second best C# programs virtually ties with Go implementation, which is not a surprise: those are pretty straightforward, calculation heavy programs. Easy to optimize so both .NET JIT and Go compiler do similarly good job generating code.
So all we've learned that using SSE2 can significantly speed up certain kinds of code but it has nothing to do with C# vs. Go.
Arguably SSE2 intrinsics are actually part of C#. Apparently they were added as a library in .net core 3 (in 2019?).
You will typically not use intrinsics in your code because a) you don't need them b) they're pain to use
And I could write a Go version that uses intrinsics and it would be equally fast.
The same applies to n-body and spectral-norm at which point I've lost interest in those benchmark because all they show is that someone spent extraordinary amount of time optimizing C# code with intrinsics while the same effort wasn't applied to Go programs.
But by constructions you average Go program will be faster that your average .NET JITted program.
JIT has constant overhead and can't spend as much time generating best machine code as offline Go compiler.
Plus .NET is more memory hungry (.NET object have memory overhead not present in Go structs), UTF-16 strings take up ~2x more spaces than Go's byte strings etc.
Doesn't mean every Go program will be faster than equivalent C# program but it's more 80% in favor of Go.
- osigurdson 4y agoI don't think I have ever seen a benchmark that concludes this. I think the best conclusion is that Go, C# and Java perform roughly the same - which makes sense since they are basically all the same thing. As you say, you could write a Go version which would be equally fast. Here is another showing Go under-performing both Java and C# by a bit. Benchmarks may not be perfect but better than conjecture. https://www.techempower.com/benchmarks/#section=data-r21 https://www.techempower.com/benchmarks/#section=data-r21
- kaba0 4y agoA JiT compiler doesn’t have constant overhead, most programs have an initialization phase and one or more hot loop. Those hot loops will be machine code soon and thus in practice there will be zero difference in a warmed up state. Also, one of the least toy benchmark out of these (binary tree) which basically just stress tests the GC shows Java and C# multiple times faster than Go. And while you may claim that “you can just use value types” with Go, GC will be a significant part of any practical application and Go is absolutely beaten in this category by quite a huge margin.
- igouy 4y agoUntil Go has memory arenas :-) https://uptrace.dev/blog/posts/go-memory-arena.html#memory-arenas https://uptrace.dev/blog/posts/go-memory-arena.html#memory-a...
- kaba0 4y agoThat’s possible in both languages in a way already and won’t be generally used everywhere as it is an optimization into which you have to put extra effort.
- pjmlp 4y ago.NET also supports AOT compilation since it exists. Intrisics are part of the standard library, it isn't .NET fault that Go designers don't want to provide similar facilities.
- igouy 4y ago> Because there are… "After all, facts are facts, and although we may quote one to another with a chuckle the words of the Wise Statesman, 'Lies--damned lies--and statistics,' still there are some easy figures the simplest must understand, and the astutest cannot wriggle out of." Leonard Henry Courtney, 1895 > So all we've learned that using SSE2… As you say, we've learned that a C# program not using SSE2 was a little faster but more-or-less the same as the fastest Go program shown. > JIT has constant overhead and… <PublishAot>true</PublishAot> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...