[Question] CoreRT future plans

[christianscheuer]

Dear CoreRT team,

Having followed this repo for now a couple of years and having developed a product depending on it, it's been quite a journey to follow the development in here. It's been very rewarding to be able to follow the progress of a compiler and runtime and I've been stoked to see that it was finally possible to do full AOT compilation of .NET. It's been a joy to watch the discussions and PRs come in one by one, slowly improving the product - thank you to the whole team for all their hard work on this!

Now for my question. During the past months I've started to notice hints about the future of CoreRT in a growing number of discussions around github and I've been surprised to see references to that CoreRT is still considered an experimental runtime and is often ruled out as a good solution for customers. Whereas initially over the first years following this, it felt like CoreRT was on a path to becoming part of the official "dotnet" CLI experience, but these recent discussions seem to indicate that the opposite is true. It strikes me that in the long discussion thread on single file deployment many of the use cases would benefit from CoreRT yet it seems like everybody is ruling it out for reasons I still don't fully understand (apart from the obvious dynamic plugin loading, but honestly there are many alternative ways to implement plugins in CoreRT, some of which we use in our product).

It seems to me that you have a stellar product here that would solve so many issues if it were on a path to official support, yet at some point along the way it was decided to not fully support it anyway. @jkotas you hinted in the discussion that the technology would likely end up in a (different) product some day, but even if that calmed my nerves slightly, it also sparked more questions, such as - can we continue to rely on this compiler for our product, or do we run the risk of it suddenly falling out of grace. I thought at one point that the decision to not officially support CoreRT was simply that it wasn't ready. But now that it feels increasingly more mature yet seems to be ruled out of official support plans, it strikes me that it might be a more strategic decision.

I know that this might be a tricky question to answer in a public forum, but please don't take it the wrong way. I'm just curious to try to understand if full AOT compilation (not CPAOT but CoreRT) is still being considered a strategic part of the .NET future.

I have noticed the efforts to unify the sources from the various runtimes which is another hint that long time development is intended. I understand that this repo serves many officially supported products, among those now .NET Native and CPAOT, which leads me to have greater trust in CoreRT going forward.

But I hope it makes sense that it would be nice at one point to gain a little clarity of what Microsoft's intentions are in the longer term in this space. In my ideal world, it would be decided to acknowledge how great of a product this already is and it would gain a permanent place on the .NET stage.

[MichalStrehovsky]

They said in gitter that Mono LLVM AOT cannot make native binaries like CoreRt, but it has potential, so isnt it better to work on the Mono LLVM AOT and modify it so it makes binaries, its much easier than keeping separate project if the difference in the end when Mono is mature is going to be just that

Miguel doesn't believe in the design that CoreRT is built around (tiny runtime where things like reflection are just addons that you can turn off). It doesn't look like Mono wants to go in that direction.

People who want to have those options are a minority, but their desire to have something like CoreRT is so strong that they're willing to leave the .NET ecosystem for Go or Rust just to get that (real native, small, and self-contained binaries).

Options are good and I believe we need to have such option in .NET.

[filipnavara]

CoreRT is written mostly in managed code and that makes it easy to understand and easy to experiment with. That alone is tremendous value in itself.

Mono is the pragmatic option at the moment. It can already do everything - JIT, AOT, Full AOT, LLVM Only mode and kitchen sink. It already is a part of shipping products (Xamarin, VS4Mac, Blazor), and, most importantly, to keep these products relevant it is necessary to move past the .NET Framework compatibility and look towards the .NET Core future.

Where the common goals made it meaningful Mono was already borrowing code from CoreRT and CoreCLR and it will continue to do so. Likewise, CoreRT is sharing code with CoreCLR where applicable. The projects don't live in isolation and while there is overlap I would not call it redundancy.

[alpencolt]

Wow! Huge discussion. We tried to use CoreRT on ARM architecture and successfully launched quite big application with more than 7.5k classes (but with some hacks😩). There some measurements and I think situation should be better on x64.

	Managed (with FNV)	CoreRT	Gain, %
RSS, MB	91	68.7	25
PSS, MB	52	48	8
Startup, sec	3.7	2.3	33
Disk, MB	18	26	-44

Tests pass rate:

Tests	Total	Pass rate, %
CoreCLR (CoreRT subset)	2206	79.5
CoreFX (CoreRT subset)	2835	100

I don't know about x64 platform but in case of ARM CoreRT is still needed additional work (we've faced with some GC issues and tests pass rate should be 100%). And in the overall CoreRT isn't common purpose solution for every one. It's generate one self contained binary and its why we see performance and memory gain (off course with optimizations based on this assumption). But from this restriction negative side is started. Like obvious lack of assembly loading and cases when we have several application (look to PSS: in case of managed runtime on system you can share memory with other application, but in case of CoreRT runtime is located inside application).

@xoofx may be interesting for you

[yahorsi]

Would be great to get some updates on how .NET 5 affects CoreRT project

[svick]

@yahorsi Doesn't https://github.com/dotnet/corert/issues/7200#issuecomment-490211974 answer that?

[PathogenDavid]

@alpencolt Thanks for sharing that data. Are there any trends with what is failing in your tests or have you not had time to look into that yet?

[mms-]

Much prefer C# to Go. But forced to use Go simply because compiling to other architectures could not be simpler. Not even a question of single file deployment, size or even JIT, simply much broader arch support (i.e. mips) and it just works.

[CShepartd]

I also prefer C# but GO have true native, clean, fast solution. I thought MS in good moment will boost up CoreRT and replace Mono but things going in opposite direction. It's just sad

[forestbat]

@CShepartd Go has less things to do than C# such as generic and reflection，and without mono，it's difficult for MS to put C# on so much platform。

[rollsch]

I would love to see a serious effort to support WPF with CoreRT. What I don't understand is how UWP is already supported, why can we not use the same engine to support WPF? The XAML compilation process surely would not be that different?

This would also massively extend the life of WPF as its performance is quite poor and there doesn't seem to be any effort to improve it.

[vitordelucca]

Talking about UWP, what's the deal of .NET Native and UWP? It seems UWP .NET Core 3 won't have .NET Native support for UWP? Will it come at least for .NET 5?

I have zero interest in developing if there's no native C# for UWP.
JIT with UWP just have awful performance, mainly the startup time. If the perf is just bad, I might just use Electron.

[rollsch]

@vitorgrs there is native C# for UWP already. But I do not know about Net Core 3 support.

[vitordelucca]

@rolandh yeah, the point is exactly the future of .NET on UWP.

[nkev]

Since 2000 I have watched and cursed that spinning circle while waiting for initial page loads on ASP.NET pages... It has never gone away, even in .NET Core. Visual Studio also seems to just get slower and buggier each year, even though MS marketing claims otherwise. Lots of spinning circles there too... :)

As much as I still love and use C# on a daily basis, Go is proving to be such a breath of fresh air for me. Super fast/lightweight/productive/enjoyable experience in VS Code and identical whether you are on Windows, Mac or Linux. It reminds of Classic ASP where everything is simple and you are in full control. No "magic" JIT delays that reduce productivity and increase frustration.

As most C# veterans would agree, an official C# AOT compiler would definitely go a long way to improve both user and developer experience. It's a shame the "new" Microsoft can't see that as a priority.

@forestbat Go does have reflection and generics is also finally coming in v2, so watchout Microsoft!

[Alan-FGR]

As most C# veterans would agree, an official C# AOT compiler would definitely go a long way to improve both user and developer experience. It's a shame the "new" Microsoft can't see that as a priority.

Exactly. I don't agree that Go is a good alternative to C# though, but that's another discussion.

[masonwheeler]

@Alan-FGR Exactly.

Go creators deserve a lot of respect, but it looks like Go's design happened in a parallel universe (or their Plan9 lab?) where most of what happened in compilers and programming language design in the 90's and 2000's never happened.

Go: the Good, the Bad and the Ugly

[bugproof]

@nkev

Since 2000 I have watched and cursed that spinning circle while waiting for initial page loads on ASP.NET pages... It has never gone away, even in .NET Core. Visual Studio also seems to just get slower and buggier each year, even though MS marketing claims otherwise. Lots of spinning circles there too...

I never used classic ASP.NET but I never experienced such issues with ASP.NET Core. I never see spinning circles and VS doesn't seem slower to me. I don't get it.

Go does have reflection and generics is also finally coming in v2

Golang v2 looks promising but it also seems like a distant future

There's also Rust but a lot of things need to stabilize and compiler performance atm is unbearable to me to use it and of course, it's not as simple as .NET

[svick]

CoreRT is dead, long live CoreRT!

Will the corert repo go away?

Yes. We plan to retire/archive the corert repo. Some of the technology in the corert repo will be migrated to the master branch of dotnet/platform, where it will be productized as part of .NET. Other portions of the corert repo will be migrated to feature branches of dotnet/platform, where the experimentation can continue. In this way, we will use feature branches to continue experimenting with the corert technology, while making it easier to share portions with its shipping counterpart and also graduate functionality into master if/when it’s ready.

[rollsch]

I want __asm in C#

And when you write x86 asm then compile it for ARM what should happen?

[charlesroddie]

@nim please stop making irrelevant posts in the wrong issues. Please delete the mess you made in multiple issues until now, make your own issue, and present it intelligently if you want others to respond and not close it.

[trampster]

My use case is for using dotnet in an embedded linux device, running on an arm chip, our biggest concerns here are startup time, and binary size. Both of which would be solved with CoreRT. My team wont consider dotnet core at this time because this is missing.

[Kein]

@svick This is why we cant have nice things

[masonwheeler]

@kein What is?

[Kein]

@masonwheeler Weird and random Microsofts' one step forward 2 backwards

[rclarke2050]

Hi, just out of curiousity, will ReadyToRun be a good alternative to CoreRT ? https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-6/

im looking at it from a point of fast cold-starts in AWS Lambda.

This post came about because i started looking into faster cold starts from : https://medium.com/@zaccharles/making-net-aws-lambda-functions-start-10x-faster-using-lambdanative-8e53d6f12c9c

[MichalStrehovsky]

@rclarke2050 ReadyToRun helps improving startup time so it's definitely worth turning on and measuring. We also made other improvements in .NET Core 3.0 to make it start a bit faster than 2.0.

But I don't think you'll realistically see a 10x improvement as Zac measured with CoreRT in the article you're linking to. CoreRT starts up faster due to a combination of factors - pregeneration of native code (which is what ReadyToRun does) is only one of those.

[Alovchin91]

Agree with @Kein. Microsoft also recently moved focus away from cross-platform Xlang project. They just keep killing stuff people are waiting for.

It's a pity, because many teams try not to spread all over different languages and keep their code base familiar. But sometimes (like for DllExports in native plugins), you just can't have a normal managed .NET assembly.

Another pain point is that in this new dotnet/platform repository we won't be able to discover CoreRT issues easily. They will just sink among all the other issues for all the other platforms. I'm afraid that labels won't last long, and we'll see decreasing commitment to respond to those issues.

In this regard, talking about the alternatives, Swift could also be considered. The language is stable enough and has its community. The compiler also is being developed to work on Windows, if anybody needs it.

Another option could be Kotlin/Native — these guys are building actual LLVM compilation to native binaries. They seem to understand the benefits.

Add Rust and probably Golang v2 (though for me it's ugly as hell), and we would have enough alternatives to unreliable Microsoft projects.

[forestbat]

Agree with @Kein. Microsoft also recently moved focus away from cross-platform Xlang project. They just keep killing stuff people are waiting for.

It's a pity, because many teams try not to spread all over different languages and keep their code base familiar. But sometimes (like for DllExports in native plugins), you just can't have a normal managed .NET assembly.

Another pain point is that in this new dotnet/platform repository we won't be able to discover CoreRT issues easily. They will just sink among all the other issues for all the other platforms. I'm afraid that labels won't last long, and we'll see decreasing commitment to respond to those issues.

In this regard, talking about the alternatives, Swift could also be considered. The language is stable enough and has its community. The compiler also is being developed to work on Windows, if anybody needs it.

Another option could be Kotlin/Native — these guys are building actual LLVM compilation to native binaries. They seem to understand the benefits.

Add Rust and probably Golang v2 (though for me it's ugly as hell), and we would have enough alternatives to unreliable Microsoft projects.

Hold your horse，MS has more than one AOT compiler such as Mono AOT（base on LLVM）/LLVMSharp/ClangSharp，and corert itself also has more than one compiler such as CPAOT，IL2CPP，wasm compiler，so don't need to be too anxious.

[Alovchin91]

@forestbat LLVMSharp/ClangSharp have nothing to do with AOT. Mono AOT tries to compile IL binaries to native images — pretty much the same as crossgen. All the other compilers in CoreRT are not considered close to stable (see Readme.md).

[oliverjanik]

Can we have just single 70mb .exe ? I know CoreRT's goal is AOT, but I really only care about having single .exe for dead easy distribution.

[Alovchin91]

@oliverjanik For many situations, 70mb is a huge overhead. Imagine an app which by itself is ~30mb, and a plugin which is 70mb just because it pulls the whole .NET with it. Sure they are working to reduce this, but CoreRT is still a lot smaller.

Now, imagine that this plugin also should have a C-style FFI to be called from that app. Okay, let's say we've configured 3F/DllExport and managed to include it in our pipeline. But we might not be the only ones who would do the same, and we don't know if any other plugins loaded by the app use other versions of .NET. What if they do? Will we get a number of different runtimes in our process, including different GCs, CLRs, maybe even mixed Core and Framework ones?

Sure we could solve it by using system-wide .NET. But what then? Do you need to make an installer for your plugin, so it also installs the right version of .NET if needed? And what if your installer also needs to do something custom, like gathering analytics, and you need to write some custom actions?

CoreRT solves all those problems by providing a small native runtime that is comparable with C++ one. Of course you still could have different versions of it loaded into your process, but they are small and hopefully don't include stuff that could interfere. Without CoreRT, you just have to go native with any other language.

[oliverjanik]

I understand the goal of CoreRT and it's a complex problem to solve.

What I'm saying is, there might be a subset of people who can simply be satisfied with actually bundling the publish directory into a single exe file.

I've got a CLI and I don't care how big it. All I care about is that installation for my users are simple and clear. 150 files vs 1 exe file makes a big difference.

[filipnavara]

Publishing as single file is orthogonal issue to CoreRT. It's already available in .NET Core 3.0 with <PublishSingleFile>true</PublishSingleFile> property added to .csproj files. Documentation is available at https://github.com/dotnet/designs/blob/master/accepted/single-file/, particularly the design document.

[oliverjanik]

Fantastic news, didn't know about that one. Thanks for the pointer.

[trampster]

Regarding size, the c++ app we have is 3 mb, the smallest I could get a dotnet core hello world to was something like 24 mb, And if you trying to actually do anything useful it gets a lot bigger. This is what you are competing against. CoreRT is amazing at this, but doesn't support arm using the dotnet build tools.

[rclarke2050]

Publishing as single file is orthogonal issue to CoreRT. It's already available in .NET Core 3.0 with <PublishSingleFile>true</PublishSingleFile> property added to .csproj files. Documentation is available at https://github.com/dotnet/designs/blob/master/accepted/single-file/, particularly the design document.

.NET CORE 3.0 is released in a couple weeks during the .NET Conf 2019 it uses "crossgen". https://github.com/dotnet/coreclr/blob/master/Documentation/building/crossgen.md

Nice example here talking about both: https://www.gdatasoftware.com/blog/2019/04/31587-native-single-binary-net-core

take a look at the Scott Hanselman's blog about R2R .NET CORE 3.0 https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

from my take, R2R will not be as fast as CoreRT, but close to it (as its a mix of IL and pure native).

lets hope they sort it out for .NET 5 ;-)

[tiandian]

R2R in .NET CORE 3.0 include all the managed il code, you can disassembly a R2R dll use ILSpy, it can make runing faster, but it can't protection code.

.NET CORE 3.0's single-file executable is just a zip file, when first time execute it, it will unzip it to a temp folder, except need more disk space to run, no practical meaning.

CoreRT = R2R remove IL code safely then merge it into a single file, it is the fastest and safest code, and need small disk space, it is the best.

[Alan-FGR]

CoreRT = R2R remove IL code safely then merge it into a single file, it is the fastest and safest code, and need small disk space, it is the best.

+1 for CoreRT

[masonwheeler]

@tiandian Obfuscation/"protection" isn't really something to be promoting as a positive feature these days. With the rise of cybersecurity awareness, it's finally starting to get a well-deserved bad name as people realize just how often obfuscation is employed by malware authors to make their bad behavior harder to detect.

"The safest code" is code that outsiders can easily audit and ensure that it's not doing anything unsafe.

[Alan-FGR]

@masonwheeler I personally would rather ship machine code instead of sources or some intermediary code, but I agree with you there. And if people really have a super-secret algorithm then perhaps simply not running that code in the client machine could also be an option these days, and no obfuscation beats that. There are however legit cases in which you might want to obfuscate your code, but they're probably rare enough that shouldn't be high priority, and you can always use third party technology for that anyway.

[lenardg]

Let me chime in by saying that I have created my entry for this years Interactive Fiction Competition using CoreRT. I had been thinking long what to start coding in, but because my day job involves .NET/C#, it felt like a good choice.

But I had a problem figuring out how to distribute the game and make it runnable for many people on multiple different platforms. The different platform dilemma is solved by .NET Core to some degree, but asking people to install something to run a text adventure is a bit of a stretch. Doing a publish for the different platforms creates a huge pile of files for each platform, which is again a difficult selling point.

Then I came across CoreRT and how it does AOT, and it works fantastic.

I compiled my console based text adventure for Windows, Linux and MacOS for distribution, and it works. People have no problem running them. I simply cannot imagine that I could have distributed my game any other way than by doing AOT.

The .NET Core 3.0 way of "zipping" might also work for me (tested that as well), but I do not like the fact that temporal files are being written to disk and there is no way to automatically clean up after the app.

Doing AOT and having a single file to distribute (per platform) is very convenient for users.

+1 for CoreRT from me too! I really hope that CoreRT/AOT finds itself a place in .NET Core!

[sgf]

I know there's an team working to reduce the size of output(exe) files by C++ on windows. And they claims to be more professional than Microsoft's toolchain. They even eliminate platform compatibility to some extent. Windows-XP is supported.

maybe little help for CoreRT output on windows ?

If you're interested,this link VC-LTL: https://github.com/Chuyu-Team/VC-LTL

[trampster]

Some people here are suggesting ready to run as a solution, this makes the deployment bigger not smaller. So for us Ready To Run makes things worse not better.

[rollsch]

I still don't understand why the netnative toolset cannot be forked to work with wpf/netcore etc. UWP surely is far more complex as a platform than netcore?

[Berrysoft]

I still don't understand why the netnative toolset cannot be forked to work with wpf/netcore etc. UWP surely is far more complex as a platform than netcore?

I think that .NET Native uses close-source code, for example, code in MSVC, which costs time for them to port to LLVM. Also, .NET Native only supports Windows, while CoreRT aims to support all platforms.

[rclarke2050]

Hi Everyone,

Im not here to bash CoreRT, I also wish CoreRT gets better coverage, adoption and MS dont pull the plug. I know this is off topic, but its worth a read nevertheless.

Im only here to give note from the aspect of performance specifically for AWS Lambda use. Zac Charles has again done a great article on R2R .NET CORE 3.0 benchmarking.

https://medium.com/@zaccharles/net-core-3-0-aws-lambda-benchmarks-and-recommendations-8fee4dc131b0

I will be watching CoreRT closely..... peace out.

[trampster]

So dotnet 3.0 even with 'ready to run ' starts slower then dotnet 2.1. That's damning indeed! We need CoreRT.

https://medium.com/@zaccharles/net-core-3-0-aws-lambda-benchmarks-and-recommendations-8fee4dc131b0

[jkotas]

@trampster Note that the numbers in this article are comparing dotnet 2.1 with native AWS support vs. dotnet 3.0 without native AWS support. I believe that the native AWS support is where the difference comes from. Once AWS adds native support for dotnet 3.1 LTS, I expect you will see 3.1 to better than 2.1 across the board.

[mhmd-azeez]

@jkotas what do you mean by native AWS support?

[jkotas]

This table: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html