Don't look at that kind of benchmark, most cheat, and notice how latency is bad, because C# is not native code, so the JIT needs warmup just like java, wich introduces hicups and non-deterministic performance
So these perfect situations where you only do the same thing and call same code over and over never happen; never!
Anyways, GO isn't popular for its RAW perf, GO is popular because:
I actually clarify right after that my claim has nothing to do with benchmarks and actual performance of the programming language.
> Go is simple so that all of this can hold true when confronting the average Go program with the average Java / C# program. It doesn’t matter whether Go is truly faster than C# or Java in an absolute sense. The average Java / C# application will be very different than the best theoretical program, and the amount of foot guns in those languages is huge compared to Go.
Not to say that I knew perfectly well where Go sat vs Java vs C# in terms of raw performance, but mine was a different point based on my experience.
I wrote a lot of C# and a lot of Go. C# has so much more ceremony that it is more verbose and it shows even in the code we're discussing. You just have to be willing to look.
Fair comparison between C# and Go is actually very easy. Those languages are so similar that you can transliterate a given benchmark from one language into another. Then benchmark those versions.
There's just no way that on an average program Go (language statically compiled to assembly with a very competent code generator) will loose in performance to C# (which compiles to bytecode and then JITs that code at runtime using a much weaker code generator).
I 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.
Alternatively, we could do apples-to-apples comparison of the benchmarks.
Go and C# are so similar that for benchmarks you can transliterate one into the other.
We should be comparing programs that are comparable.
My point is that BenchmarksGame is not comparing comparable programs.
Code for some languages has extreme optimization, including doing things that most people don't do in day-to-day programming.
Go supports assembly. Given enough time I could probably implement a given benchmark in assembly, beating C# (and pretty much anything).
This is used to good effect in Go runtime and some really niche applications but in real life I don't have infinite amount of time to micro-optimize my code and write parts of it in assembly.
What I want to know is the performance of competently written code.
I agree that my wording is too strong due to my memory of the latency results. As you increase the load, Go is closer to Rust/C than C# (see last benchmarks) and at a given load, C# isn’t in picture. It’s fair to say that Go/C# is similar while Java is far behind depending on the benchmarks that are important to you.
Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.
There's a variety of possibilities. Lerc mentions GC as one possibility, which could definitely be the case. Another one that would be high on my "first guess" list is that everything above it has much better optimizers, and raytracing code is one of the places this is really going to show. Go does basically very little optimization, because it prioritizes fast compilation.
(Where Go "wants" to play is that same benchmark, except including compilation time.)
A couple of the things below Go I suspect are bad implementations. I would expect a warmed-up C# to beat Go if both have reasonable (not super-crazy optimized implementations) or at least be at parity, and Luajit may also be a slow implementation. In both cases because ray-traced code is a great place for a JIT to come out and play. EDIT: Oh, I see C# is Mono, and not the Windows implementation. In that case that makes sense.
Oh, and I find it helpful to look at these things logarithmically. I think it matches real-world experiences somewhat better, even though we truly pay for performance in the linear world. From that perspective, it's still only the second largest. The largest is Haskell to Elixir, which is substantially larger. O'Caml->Go is large, but not crazily so; several other differences come close.
What do you mean? Even C# is measured in millions of lines per-second. The only compilers that are kind of slow these days deal with complex static type systems (Scala), whereas Go has a simple static type system and should compile fast.
The fact that Go is slower than C# really amazes me! Not long ago I switched from C# to Go on a project for performance reasons, but maybe I need to go back.
"C# is faster than Go" do you have some links to prove that statement ? I'm really interested because in all the benchmarks I saw, C# seemed much more slower.
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.
I was a little skeptical of this claim, so I looked it up. C# winning happens in a handful of cases, but it's extremely rare. Go practically always wins on memory usage, even if it doesn't win the cpu benchmark.
Still loses to .NET. On reference host Java still closer to 1.7-2s ballpark (and has to use awkward SWAR to get there) while the fastest solution in C# is 1.2s, beating C++ (code can be ported however).
But yes, "I expected Go to win..." is exactly the core of the problem here. Same as with e.g. Swift, which people expect to perform on the level of Rust, when it is even slower than Go. The intuition caused by common misconceptions just does not correspond to reality sadly.
I know of the techempower benchmarks. You'll notice that the go results that end up scoring highly are using "atreugo", a customized low allocation implementation. That's how it gets its speed. Java and C# on the other hand are using fully fledged framework implementations (e.g. Vertx or ASP.NET).
You end up with a highly customized implementation not suited for wide use to get the higher performance benefits (and it still doesn't beat java on benchmarks like single/multiple queries and JSON serialization).
All these benchmarks should be taken with a large grain of salt. The golang compiler doesn't even pass function variables in registers (they're all stack allocated as far as I know), let alone do any of the advanced inlining and optimizations the JVM does.
So these perfect situations where you only do the same thing and call same code over and over never happen; never!
Anyways, GO isn't popular for its RAW perf, GO is popular because:
- Simple language
- Native code
- GC
- Cross compilation
- Fast iteration (build/rebuild/deploy)
- Relatively tiny, statically compiled executable
reply