Live data from Hacker News

Golang vs. C# (.NET 5.0) at Benchmarks Game

benchmarksgame-team.pages.debian.net

1–10 of 114 posts

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#3
When you see how much effort it takes to C# and Java to optimize the runtime, there are a lot of people working on that. C# is fast but you see that it uses between 2 and 32 times the memory that Go needs.

Overall you can see how fast Go is, it has little optimization compare to C# and it's as fast. Compare this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and overly complicated C# version: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ( avx, Intrinsics etc ... )

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#4
I was always under the impression that Go never had a great optimizing compiler. It was never a primary focus given the limited developer resources.

I couldn’t find a direct C# to Rust comparison but Rust trying to compete with C++ means performance is a goal, if that’s what you are after.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#5
I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure).

Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#7
post #3

When you see how much effort it takes to C# and Java to optimize the runtime, there are a lot of people working on that. C# is fast but you see that it uses between 2 and 32 times the memory that Go needs. Overall you can see how fast Go is, it has little optimization compare to C# and it's as fast. Compare this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and overly complicated C# version: https:…

I definitely have run into this, even when using 'server mode' in asp.net core. I never was able to figure out why the C# version of my POC was using so much memory, but rewriting to golang ended up using a very predictable, minimal amount of memory in comparison.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#8
I can't imagine a better setup for a language flame war :). I really like debating languages, so I hope it doesn't go that direction.

One of the standard caveats with this particular benchmark game with respect to Go is idiomatic optimizations are prohibited. To use the btree example, Go's memory management is low latency and non-moving, so allocations are expensive--any Go programmer writing a performance-sensitive btree implementation would pre-allocate the nodes in a single allocation--an absolutely idiomatic and trivial optimization--but the benchmark game requires that the nodes are allocated one at a time. In other words, the C# version is idiomatic, but the Go version is expressly contrived to be slower--not a very useful comparison.

Mad respect for .Net though; it's really impressive, I like the direction it's going, I'm glad it exists, etc.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#9
post #3

When you see how much effort it takes to C# and Java to optimize the runtime, there are a lot of people working on that. C# is fast but you see that it uses between 2 and 32 times the memory that Go needs. Overall you can see how fast Go is, it has little optimization compare to C# and it's as fast. Compare this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and overly complicated C# version: https:…

I definitely have run into this, even when using 'server mode' in asp.net core. I never was able to figure out why the C# version of my POC was using so much memory, but rewriting to golang ended up using a very predictable, minimal amount of memory in comparison.

My guess is that golang's GC is optimized for latency at the expense of throughput, limiting the max memory size.

Re: Golang vs. C# (.NET 5.0) at Benchmarks Game

#10
post #4

I was always under the impression that Go never had a great optimizing compiler. It was never a primary focus given the limited developer resources. I couldn’t find a direct C# to Rust comparison but Rust trying to compete with C++ means performance is a goal, if that’s what you are after. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I don't think it was "limited developer resources" so much as a desire to preserve blazing-fast compile times. The very rough rule-of-thumb that I've heard is that optimizations must pay for themselves (a compiler which is itself compiled with the given optimization must not be slower than the previous version).
Post reply on HN