CoreRT – .NET Core runtime optimized for AOT compilation | Hacker News Reader

CoreRT – .NET Core runtime optimized for AOT compilation

github.com

135 pointsjeswin19 comments

I don't get it. Wasn't this already released under MIT like two years ago?

I would also appreciate a little comment on this because the readme doesn't do much explaining what it is, why it's important, how it's different from .NET Core 2 compiler? To put it in another way, why is this so relevant?

Seems like this can/will target webassembly.

The is already a partial backend for webassembly in the repo.

It is the POSIX version of .NET Native, for AOT compilation into native code.

Using a much better compiler backend than NGEN, similar to Mono when targeting iOS.

Additionally, it is also adding WASM as target "CPU".

.NET Core only does JIT currently, the generated binary is a mini-bootstrap code that starts the runtime and feeds the main application Assembly into it.

Thanks for the explanation. It’s good to see that Microsoft finally decided to port .net native to other platforms than uwp.

The dot net foundation has released a lot of the language components, this appears to be a different compilation target.

It looks like this project skips the common intermediate language, and compiles straight to native processor code or Web Assembly (Ahead of Time compilation).

You get to skip the overhead of Just In Time compilation.

> common intermediate language

I think you are referring to MSIL

Nope https://en.m.wikipedia.org/wiki/Common_Intermediate_Language

Common Intermediate Language is the standard name for MSIL.

More info in `Documentation` folder:

https://github.com/dotnet/corert/blob/master/Documentation/i...

https://github.com/dotnet/corert/blob/master/Documentation/h...

I would love to see more of a road map on where this project is going. It's exciting, but not clear where it's heading.

So using this a .Net application run without the .net framework?

Precompiled, and the framework is delivered with it. This repository is a work in progress of getting .NET to run like a native application. It features multiple targets, not only desktop, but also browser via wasm or, the most interesting, is compilation (transpilation?) to C++ and therefore supporting more platforms than otherwise possible.

The .Net VM compiles its code "just in time", this is compiling "ahead of time" while still running on the .net framework. You're thinking a little more along the lines of .net's 'NGEN', used to create native images.

This ahead of time compilation is smart for server solutions where cold start time is an issue, certain kinds of complex projects where start times become an issue, or for small devices where start times are among the biggest usability issues ever.

I thought server stuff is the place where startup time doesn't matter that much compared to interactive applications on the desktop. At least that's historically one of the major difference between the client and server runtimes of both .NET and Java.

Well, that's a definition question :)

You're dead on -- proper "Server" solutions, like we see in architecture diagrams or on back-end tiers, are generally insensitive to startup times. As a rule they're spooled up before being connected to the larger app, or are 'the app' itself and have load balancing or operational pauses to mitigate up-time effects (where necessary).

In 2020, though, as people are working with microservices and containerized server deployments you end up with a lot of 'servers' where 'apps' used to be. Particularly for focused web apps initial startup time can be a major issue in a shared environment. That's where NGEN or AOT can come into play to happily minimize startup time and memory demands. Parallel computing and number crunching loads can also benefit if you're looking at lots of short lived servers, or a domain that challenges the compiler for whatever reason.

The framework is included with the application, so no install is needed. You can already generate a self-contained platform-agnostic deployment that includes the framework, but it contains lots of files. You need to specify the platform, yet that is just for the bootstrapper. There are also some pre-requisites that have to be installed, such as SSL libs.

.NET Native (a.k.a. CoreRT) is more like what you get with Go, a single native binary. You need to know the CPU architecture ahead-of-time, but it has performance advantages. You can also strip out unused code with IL Linker and do things like Profile Guided Optimisation.

Keep in mind that if you're using Docker containers then you probably want to share the framework, otherwise this will increase the size.

There's some more discussion around this in the .NET Core talks that I've given: https://unop.uk/talks/

> .NET Native (a.k.a. CoreRT) is more like what you get with Go, a single native binary.

I think this really needs to be emphasized, it's a great feature and this was the one question I had when I clicked the link, but I didn't get the answer until I came here.

Reply on news.ycombinator.com