Comment by vmarsy | Hacker News Reader

Comment by vmarsy | Hacker News Reader

Parent Full thread

Very interesting! No matter what the original intent was with Midory, writing an OS in C# and gain insights into what is wrong in C# Performance-wise is great. All of these findings can have impact on every C# program out there: a web server isn't considered "Systems programming", but it's not going to say NO to performance improvements

In the slides posted by pjmlp[0], I found one slide particularly interesting: Slide 38 about Contracts:

   Contract.Requires(buffer != null);
   Contract.Requires( 
     Range.IsValid(index, count, buffer.Length)
   );

or the Debug variant of it :

  Contract.Debug.Requires/Assert/Fail

It reminds me of the Dafny programming language[1], but here this seems to be used for performance. The future C# AoT compiler could be validating those Contracts, and from these Contracts enables more aggressive optimizations

The slide about PackN (and future "Safe" stackallock) is also great, it seems like the easiest optimization someone can apply to its current code.:

  int[] array = new int[8] { 0, ..., 7 }; 
  // Heap allocation!  For short-lived arrays, this is bad!

Versus the proposed "Safe":

  Span<int> span = stackalloc int[8] { 0, ..., 7 };

[0] https://qconnewyork.com/system/files/presentation-slides/csy...

[1] http://research.microsoft.com/en-us/projects/dafny/

>writing an OS in C# and gain insights into what is wrong in C# Performance-wise is great

In some ways, yes, but was C# ever intended to be a systems language? No, and that's obvious from its design. So, what is this really telling us? That the language has issues when used in a way it was never intended to be used?

I see your point, For me, it's more in the spirit : "Hey look C# used as a systems language really pinpoints performance problems X, Y, Z."

Improving the compiler to better handle X, Y, Z will yield to improvements all over the spectrum, not only in systems programming. C# used as a systems language only helped us find those issues faster.

Short-lived stack allocated arrays, zero copy, etc. isn't something only systems programmers need. if your average ASP.Net webserver can benefit from it, it's a good thing.

In the 90's C programmers used to state that C++ wasn't a systems programming language, now their main FOSS compilers are written in C++.

On top of that, even some L4 microkernels are written in C++. So, efficient that they fit into a L1 cache as they run ulta-fast. I keep trying to get people to not use C++ for these but funny it's almost a trend now.

> I keep trying to get people to not use C++ for these but funny it's almost a trend now.

I can understand why L4 choose C++ at the time, as it had stricter checking than C, but OS kernels have very little internal code reuse that necessitates inheritance or templates. This is doubly true of microkernels. There is literally no reason to use C++ in this domain. Ada or C, and soon Rust should be the only considerations IMO.

Total agreement. :)

Arguably C++ in the 90s is a different beast than C++11 and later.

Those compilers and OSes written in C++ were started when C++98 was the latest version available across all major compilers.

> The future C# AoT compiler could be validating those Contracts

If you install the CodeContracts verifier, it does.

Reply on news.ycombinator.com