New experimental runtime

[deeprobin]

Hello all,

I would like to bring up for discussion an idea that has been bothering me for quite some time. My demanding time management has so far prevented me from developing a proof-of-concept. However, I am convinced that there is plenty of potential in this vision.

Please consider the possibility of an additional runtime based on Rust that exists in parallel with CoreCLR and Mono.
Initially, this would be an experimental endeavor, but it could have considerable benefits.

The performance and memory safety of Rust are recognized advantages that probably have not escaped many.
Runtimes such as Cranelift (currently powering wasmtime) have already proven that Rust-based JIT runtimes can be efficient and powerful.

A new runtime in Rust would not necessarily have to focus on codegen optimizations for specific architectures.
Rather, a bridge could be built between .NET components such as the IL parser, garbage collector, threading, etc. and the underlying runtime. This could involve implementations in Cranelift and via FFI interfaces to LLVM.

graph LR;
    A[.NET/CIL] o--o B[The New Runtime Interface];
    G[Codegen] o--o H[x86/x64];
    G[Codegen] o--o I[ARM];
    G[Codegen] o--o J[MIPS];
    G[Codegen] o--o K[RISC-V];
    G[Codegen] o--o L[More architectures ...];
    C["Underlying Runtime (e.g. Cranelift, LLVM)"] o--o G[Codegen];
    B[The New Runtime Interface] o--o C["Underlying Runtime (e.g. Cranelift, LLVM)"];
    B[The New Runtime Interface] o--o D[Threading];
    B[The New Runtime Interface] o--o E[COM];
    B[The New Runtime Interface] o--o F[Other runtime aspects ...];

Loading

This approach could promote greater transparency, structure, and modularity in the code, making the project more robust and maintainable overall.

While some proponents prefer a runtime written in C#, I believe that .NET and Ahead-of-Time (AOT) compilation are currently not optimally equipped for such complex tasks.

By considering Rust as the language for this new runtime, we could achieve a balance between modern, security-oriented language features and the need for high performance and efficiency.

Certainly, developing such a new runtime would require a certain amount of time. But I could imagine that .NET could once again be taken to a new level.

Please leave your thoughts, criticisms, ideas on this proposal.

[EgorBo]

Certainly, developing such a new runtime would require a certain amount of time. But I could imagine that .NET could once again be taken to a new level.

It seems like it has zero advantages over spending those efforts in rewriting the runtime pieces in C#/NAOT instead:

1. Less pinvokes
2. IL-trimming with user's code
3. Perf improvements from dogfooding
4. Faster compilation
5. Easier to prototype new features

[deeprobin]

How would you initialize such a new runtime in NAOT, for example?
.NET is basically a language that requires a garbage collector. Of course, manual memory management is also possible, but the startup also needs some memory, right?

Is it possible to initialize NAOT without a predefined memory management?

Regarding point 4. it is definitely the case that Rust unfortunately has a slow compile speed, but the source code is of course very optimized.
Cranelift is actually a runtime that specializes in JIT, although AOT is of course also possible. Therefore, Cranelift has a pretty fast compile time.

---

Are there currently any plans or PoCs for a new C#/NAOT based runtime?

[EgorBo]

NAOT itself is a fully managed runtime except the GC and JIT parts (JIT is used to emit AOT code for it) - so it's a great example of something rewritten in pure C#. Ideally, CoreCLR runtime could be fully managed too, but that is just a lot of work, we already made many internal calls to be C#-only over the last several years.

[En3Tho]

If anything, I think aot compiled jit/ee in C# might benefit from reusing the same GC as .Net "user code" does. It will be much easier to track how much memory jit/ee parts consume, what objects are there, what can be optimized etc.

[hez2010]

Even if we choose to rewrite the native part of runtime, we will instead choose to rewrite it in C# because this would allow us to inline internal calls to the runtime without any FFI approach and enable runtime code trimming.

I totally don't see any advantage of rewriting the runtime in Rust.

[hez2010]

It's the same as of JIT.

[AartBluestoke]

It's the same as of JIT.

doesn't the JIT use runtime hotspot optimisation and knowledge of the currently running platform to be slightly better than AOT, things like correct loop unrolling size, function size for inlining, de-virtalisation of hot type paths? - things that AOT can't prove so can't do?

[hez2010]

AOT can see the code from the view of the whole program, so it can automatically make your classes sealed and devirtualize calls. As for PGO, we also have static PGO that allows you to feed instrument profile into the AOT compiler.

[deeprobin]

A hybrid compilation would actually be optimal. A mixture of AOT and JIT.

1. the AOT compiler optimizes as much as possible to take load off the JIT compiler.
2. the JIT compiler can then optimize even more, because basically a JIT has more information. E.g. any runtime information.

In practice it is known that AOT is usually faster. In theory, however, JIT could be even faster, since JIT has more information on the basis of which JIT could optimize.

[En3Tho]

.Net is already doing this hybrid approach which is called ReadyToRun e.g. precompile code for faster startup and then jit it based on pgo/arch. The downside is bundle size.

[alexrp]

Hot take: I don't think Rust actually offers any particularly meaningful advantages for a runtime system like CoreCLR/Mono.

The portions of the runtime that deal with threading and GC will never be able to take advantage of Rust's semantics because those subsystems are beholden to .NET semantics at the end of the day. For the JIT, memory management is nearly a non-issue; compilers tend to have very predictable and understandable memory management patterns.

[frankhaugen]

Is that such a hot take? Rust is GC over sys and machine calls, just like .net is.

Rust is just such a thing right now because all the Java people who aren't allowed to migrate to Kotlin found it easier to convince their management that Rust is "safe C++" so the sales pitch was easier, because everyone and their grandma knows that C/C++ is where all the speedy code is written.

Personally I think Rust is fine, and OPs idea is maybe a decent PHD thesis, because it's interesting; I'll give them that.

[Epacik]

Rust is GC over sys and machine calls, just like .net is.

Tell me you don't know how Rust's memory management works, without actually telling me you don't know how Rust's memory management works.

Rust doesn't have a Garbage Collector.
Instead it has a concept of Ownership, and a Borrow Checker.
What's the difference?
Long story short: instead of checking if a value is referenced anywhere at runtime,
compiler checks at compile time when values can be freed and adds some code to free those values.
That way you don't have to use a GC, and you don't have to free memory manually.

Here's some more info about memory management in Rust.
Ownership
References and borrowing

[Clockwork-Muse]

Rust is GC over sys and machine calls, just like .net is.

Rust is GC the same way C++ smart pointers are GC, which is not like .NET.

[En3Tho]

Crashing the process is technically a GC over sys and machine calls too.

[ghost]

Rust could be gradually used for additions to or select portions of, the existing C/C++ runtime code base.

[huoyaoyuan]

C with class is currently gradually used as an addition of C with macro in this code base. It hasn't widely adopted recent C++.

Ownership check of Rust provides zero or negative benefit for the code manages objects on GC heap, which is effectively an external system.

[ghost]

I think that legacy OO is fading and FP with mutability controls and pattern matching is the better way. Rust impl and C# extension methods support FP with OO call syntax. Perhaps lack of use of Rust in .NET is more of a tooling and business/logistics issue than a design issue. E.g. Mark Russinovich advocates for Rust, yet I see it nowhere in the .NET infrastructure and Visual Studio does not natively support it. It is understandable that a company that owns a major platform would want to use tooling and languages that are under company control. E.g. Microsoft has C and C++ compilers but not a Rust compiler. Avoidance of a dependency on a third party compiler is understandable.

[Clockwork-Muse]

Rust uses the Microsoft linker on Windows.

As has been mentioned in other issues, if we moved away from the native runtime implementation it would most likely be changed to C#, for a variety of reasons.

[ghost]

Thank you. C# makes sense as performance increases. At that point, some minimal C would still be understandable. No F#? By the way, when I say, FP, I mean practical FP, .e.g. with normal arrays for CPU cache and some imperative code. Still, all high performance primitives can be used from the higher-level functional approach code (so clean and robust). Delegate and interface concepts also still important of course.