Hacker News Reader

Comment by neonsunset | Hacker News Reader

I find the note unfortunate. They state 2-4x performance improvement. I'm sure looking at the implementation with a profiler and tactically optimizing critical paths would have yielded them 2-3x as is. They could have also reached out to .NET JIT team via issues or discussions on GitHub for guidance. Especially since .NET has rich set of SIMD APIs very well suited for implementing SOTA text search algorithms (and also comes with many out of box, seriously, look at e.g. https://devblogs.microsoft.com/dotnet/performance-improvemen...)

The note also states "No framework dependencies (CLR or JVM virtual machines)" which isn't true either - 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' gives the same "dependency-less" experience. "Ahead-of-time instead of just-in-time compilation" is similarly wrong - replace previous args with '/p:PublishAot=true' and you get a native binary.

View on HN

The 2-4 speed ratio was not meant to denounce C#, which is a great language I loved to program in for over two decades, coming from Delphi. Unfortunately, C# has not a complete SIMD support. See our request to support the SSE4.2 _mm_cmpistrm instruction https://github.com/dotnet/runtime/discussions/63332, which we required for a vectorized intersection between two sorted 16-bit arrays. We did the switch from C# to Rust not light-minded, as the cost of porting a fairly large codebase is time-consuming. We just wanted to share our experience for our specific task, not as a general statement.

Thank you. It is indeed true that .NET has some gaps in its SIMD API, which might require either writing a specific routine in C and pinvoking it or implementing the algorithm differently.

Were there any other factors that contributed to the decision?

FWIW I forwarded the issue the discussion links to dotnetevolution discord server.

Yes. We waited long for AOT compilation to become mature, to remove the need for the user to install the .Net framework. But two years ago when we decided to switch, we still couldn't just get the AOT compilation of our codebase to work without changes (perhaps it was somehow possible, but the available documentation was not very verbose about this). Also, there is still a performance gap. Of course, this doesn't matter for most of the applications, where the completeness and consistency of the framework, and the number of programmers fluent in that language might matter more. But for a search server, we needed to carve out every inch of performance we could get. And other benchmarks seemed to echo our experience: https://programming-language-benchmarks.vercel.app/rust-vs-c...

That specific suite is...not the best. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is more focused on optimized implementations and showcases where the performance of .NET places given submissions someone cared to spend some time optimizing.

It is true that 2 years ago NAOT was in its infancy, it has improved substantially since then. Self-contained trimmed binaries already worked back then however.

I guess it is more about unfortunate timing than anything - even the compiler itself moves fast and in some areas the difference in codegen quality is very significant between 7, 8 and 9.

Reply on news.ycombinator.com