Golang vs. C# (.NET 5.0) at Benchmarks Game (opens in new tab)

> The point of the btree example is to test how good programming languages are at allocating tree-like structures that can't be preplanned.

Forcing allocations for every node isn't justified by a desire to demonstrate dynamically sized binary trees. A naive dynamically-sized tree would just keep a list of node buffers and allocate a new node buffer every time the previous one fills up (perhaps with subsequent buffers doubling in size). The benchmark is, by all appearances, contrived to be slower.

And these rules are particularly bizarre. Rust, C, and C++ are all allowed to use custom allocators while Java and C# have GCs which are optimized for this particular micro benchmark but not for real world applications (although I hear Java’s GCs are making good headway on latency lately, and clearly all of the GCs are suitable for general application development). So it’s really just Go which is forbidden from an idiomatic optimization as far as I can tell.

This one?

https://news.ycombinator.com/item?id=28274485

> Which is not accepted for the C# programs either.

Because C# doesn't benefit from this kind of optimization. Its GC is generational, which means that it has very fast allocations at the expense of high latency. In most applications, lower latency is more important than slower allocations (not least of all because these batch-allocating optimizations are nearly trivial), but these benchmarks don't reflect that at all.

> The requirements were contrived in April 2008. afaict Go initial release was March 2012.

Contrived = "the rules artificially prohibit idiomatic optimizations". It doesn't require that the maintainers have a prejudice against Go (although as you point out, the maintainers have had a decade to revisit their rules).

Server mode is much less likely to incur GC. Were you causing enough memory usage to force your app to actually free memory?

It will intentionally use more memory for the sake of throughput, hence why this post has all .NET program flag for it, as it's a _speed_ benchmark primarily.

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

I think you mean structs (value types. Will be called primitive types in Java). Records are not too interesting from a performance pov (and java has them, and I think they actually predate c#’s), though java will likely be able to optimize serialization/deserialization of records better.

Java recently added record types.

Are we looking at the same file?[0]

Tons of very "interesting" attributes like this:

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

[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I’m on a project I created in .NET 1 and then migrated to 2.0 (to generics) early on. It’s moved through VSS via svn to git. It has gone from VS 2002 on CD’s to VS2019/2022. It has over 100k commits. Still work full time on it today. I share your experience with the migrations. Never an issue. The new sdk (“core”) style project system was probably the largest blessing of this whole journey.

I actually created a .Net Enterprise app that went on to become an industry leading application.

At the time I was hired, it was to modernize an Access application used internally, to try to sell it as a product.

.Net was still in beta at the time (this was early in 2001). I figured I might as well go with the flow and try it out.

It was a crazy ride, and I've since left the company ... but we went through every version from beta through 4.8 before I left.

I'm now using .Net 5 in Azure to power my new company's REST APIs.

Well, without starting a flamewar (.NET is an impressive runtime), the JVM is better at backwards compatibility, I think.

Yes, use Rider and .net core - everything works on non-windows platforms (working on .net from osx right now, deploying to linux)

Avoid vscode for C# development, unlike TS/JS (which is top of the line), the support for C# even in core is toy level.

Yes, JetBrains rider is IMO superior to VisualStudio these days, and I run a huge amount of C# code in production on Linux. It was definitely crippled in the past but it's a first class citizen in the .NET ecosystem now.

Also relevant... can you learn it, build it and deploy it for free?

I've always thought the whole ecosystem looked really productive, and the code I've had to review occasionally looked well structured and readable. But when I was starting out MSDN cost a fortune and I've never really considered trying to learn it.

Especially with lsp-mode, C# on Linux (or Mac) is a great experience.

https://0x85.org/csharp-emacs.html

I use Sublime and it works well.

dotnet publish -r linux-x64

Seems pretty simple. Though the binary size is definitely not on par with go.

Microsoft created .NET and Azure and a lot of the tooling so the integration is tight, now that it's multi platform and with Rider (multiplatform .NET IDE) being as good as if not better than Visual Studio there is nothing stopping it.

In what way do you consider F# better than scala? Especially with the recently released, revamped Scala 3?

"He used the compiler's self-compilation speed as a measure of the compiler's quality. Considering that Wirth's compilers were written in the languages they compiled, and that compilers are substantial and non-trivial pieces of software in their own right, this introduced a highly practical benchmarks that directly contested a compiler's complexity against its performance."

p44 "Oberon — The Overlooked Jewel" Michael Franz, in "The School of Niklaus Wirth".

https://www.google.com/books/edition/The_School_of_Niklaus_W...

How often have you met compiler bugs? Also, humans absolutely can’t produce better code than compilers, at least not reliably. All those minor improvements that compilers routinely do does add up. And noone wants to write arcane hacks that make code unmaintainable and may not even provide a performance benefit (CPUs are finicky beasts, sometimes the seemingly worth option is faster)

I very much want my computer to work as hard as it can to make my code more performant for free. What I would like to see more is a separate debug and release build mode, where the former can go as fast as it can without optimizations, while the latter can be as slow as it wants and result in the most optimal binary it can produce. Zig does that for example.

Especially with the .NET Standard Library. It has damn near everything already out of the box with 1st class support, and if not there's almost certainly a nuget for it. C# is an extremely productive language to develop for.

I ran multiple search queries. I wouldn't be so dumb to post a comment like this here without having done my homework. The best I found after trying numerous keyword permutations was https://salsa.debian.org/benchmarksgame-team/benchmarksgame, but this did not appear to contain all of the benchmarks' source, just the source embedded in HTML, which is specious at best. This repository looks mostly like frontend HTML and chrome, not a SUT, executor, nor even the sub-test code.

At the very least, I couldn't realistically re-run some of the example benchmarks from the source embedded in the HTML, because they did not include vendoring/version information for external packages they depend on. That made me doubt the provenance of https://salsa.debian.org/benchmarksgame-team/benchmarksgame.

Scala code is backwards compatible, only the class files are not - so at most dependencies could have become stale. With a recompile, the programs should work just fine.