Hacker News Reader

Comment by AlEinstein | Hacker News Reader

Surprisingly good performance for the C# implementation!

The new cross-platform .NET Core framework and runtime has major performance upgrades in the last few years and the newest v3.0 release [1] in a few weeks will have even more including hardware intrinsics [2]. There are several optimizations I can see in the C# source to make this implementation even faster.

1. https://devblogs.microsoft.com/dotnet/performance-improvemen...

2. https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...

Unsurprising if you've kept up with .net The new primitive types (spans) allow direct low level manipulation of memory slices. A NIC driver, at it's core, really only copies data to and from shared buffers, so it gets a tremendous benefit from this new type.

C# recently getting new low level memory types definitely gave it the edge there, it does not reflect real world scenarios very accurately.

> C# recently getting new low level memory types definitely gave it the edge there, it does not reflect real world scenarios very accurately.

In my experience, C# is by a large margin the most performant "managed" language vs. Java, Python.

If you go down to bytecode engineering you can create some seriously fast JVM code. But I agree that making .net go fast seems easier than getting the JVM to go fast (if anything because many of the standard libraries are anything but fast, and you have to go hunting for high performance ones or roll your own).

Was going to say much the same thing.

I ported a C hash function to C# recently, and using the low-level feature that C# offers, performance was very close to the C version.

C# is really nice to work with for this kind of thing.

And - .NET Core 3.0 introduced support for hardware intrinsics, so I could probably bridge the gap if I spent some time on vectorisingthe C# code.

Microsoft has been tinkering with systems stuff in C# for years so I'm not surprised[1]

1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)

Astonished to see it perform so much faster than Ocaml. I had to double-check to see that they compiled a native binary (ocamlopt)

https://github.com/ixy-languages/ixy.ml/blob/master/app/dune...

The OCaml version is probably our most optimized implementation, it was scrutinized (and improved) by lots of people at the MirageOS retreat earlier this year.

Any ideas as to why it (ocaml) ends up being so slow?

For me, that was the line that surprised me the most. The .NET VM has had a reputation as being a worse variant of the JVM, but it seems that now the tables have turned.

Really? To me it was always a runtime VM done right! The .net CLR is much more stable, leak-proof, and performant in my experience. I have .net services that run on servers for years without ever being restarted.

Given that C# and "Rust" are neck and neck, I'd rather have a nice GC language to work with.

Go and C# are pretty much neck and neck until the batch size gets large. Rust is always ahead of C#.

C and Rust are really close, but if you look at latency C# is still lagging behind (Go performs way better in that regard).

I’d guess (cause I’m lazy and don’t want to verify the code) that it’s because the CLR has much better unmanaged support. It’s a first class feature.

Indeed. It was designed to interact with C APIs directly from day 1 and they've made it more powerful fairly recently with Span<T> and Memory<T> (essentially "safe pointers").

You can literally develop entire applications in unsafe mode, with C's level of unsafety. Nobody does, but you could.

Where did you see that? I've never come across that reputation before, only that the JVM has more usage (in high-perf scenarios) because it was cross-platform and had a bigger community.

.NET always had very good performance and the new .NET Core cross-platform framework and runtime is now consistently among the fastest in various performance benchmarks for all kinds of applications.

> but it seems that now the tables have turned.

I'm not sure that's the conclusion to draw from a niche benchmark.

it has been around five years since that was even vaguely true

Oh man, yes they have. For a couple years now the CLR has surpassed the JVM in straight-line performance for many workloads. A lot of effort has been going into providing escape hatches without sharp edges for getting closer to the hardware with the likes of Span<T>, Vec, and the upcoming hardware intrinsics. It always started faster..

As someone on Team C#, I bet my career on it after careful consideration and comparison with every other option I had on the table, I had the exact same thought. But it's Microsoft, in my opinion they know software better than anyone around. They cover a lot of ground and fail sometimes but overall I consistently have high expectations from them. I use their platform everyday. Good work, Microsoft!

If only the MS stigma would go away people would realise how amazing C# language is.

The MS stigma isn't going to go away as long as MS insists on shipping telemetry with .Net core.

I agree, but to me that's an odd phenomenon. I didn't grow up with that stigma and not sure what age/group it affects more. I started on a Commodore, which used Commodore BASIC (based on Bill Gate's Microsoft BASIC). As far as business criticism against them, I view the underlying economic system that allows and perpetuates it as the culprit. Not a single entity like MS, Amazon, Oracle etc. I'm not a cherry-picker, not productive and it's not rational. Bad actors are smacked down and it would be all of them if they thought they could get away with it. I'm in favor of changing the business model, not harping on the "new bad guy" every few years. Today it seems to be Google.

I think it's mostly a lack of insightfulness and thought that leads to cherry-picking bad guys when the system is structured in a way where unscrupulous behavior is worth risking. I could be wrong, maybe Microsoft is evil incarnate but at the level I operate on, I don't see it.

But yes, no reason to not embrace the good parts from Microsoft, or anyone else. That's how I do it. I chose C# to stick with because I believe in what they're doing around it. Huge fan of Blazor, appreciate their focus on long-term support, their product integration, and their excellent tooling. The language is good, and I can get a job doing it anywhere in the country without being in a major metropolitan area. In some of these metrics, I personally don't think you can beat the C# ecosystem.

Reply on news.ycombinator.com