corert
corert copied to clipboard
dotnet
[Question] CoreRT future plans
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.
Hello Christian,
I am sorry, but there is not much new at this point beyond what I have said in https://github.com/dotnet/coreclr/issues/20287#issuecomment-447122236 .
We definitely do want to have a great full AOT compilation story as one of the officially supported deployment options for .NET Core eventually. It is not happening for .NET Core 3. We have not really started planning for .NET Core 4.
I have noticed the efforts to unify the sources from the various runtimes
Yep, we have been working hard for a while (2+ years actually) to share and unify between all actively developed .NET Runtimes (CoreCLR, Mono and .NET Native/CoreRT). It reduces our engineering costs and in turn gives us more freedom with shipping runtimes optimized for different scenarios.
cc @richlander @MeiChin-Tsai @jeffschwMSFT @swaroop-sridhar
Hi Jan,
Thank you so much for your answer, I really appreciate it.
We definitely do want to have a great full AOT compilation story as one of the officially supported deployment options for .NET Core eventually. It is not happening for .NET Core 3. We have not really started planning for .NET Core 4.
I'm very happy to hear this. My concern was less about timing than about long term commitment and knowing that this is still being actively considered. It's great to hear that I was reading the efforts around unifying the runtimes correctly and that it will make supporting CoreRT easier in the future.
I do think that once you can say with confidence "Now we support full AOT in .NET", you will start attracting a league of programmers that would otherwise not consider .NET.
Keep up the good work!
The quality of development in this repo is highly impressive, and the response to user issues also.
The repo does suffer from a lack of planning and documentation. A particularly bad example:
The current state of platform support: Windows, MacOS and Linux x64 w/ RyuJIT codegen: Simple apps
You might as well say "mostly harmless". The real story is good support for complex apps, with the exception of fiddly reflection, and lack of support for most .Net UI frameworks.
My advice for this repo is:
- Things that are easy, not technically interesting, but highly important to users are often not being done at the moment. Updates on progress on the main page is one. The state of rd.xml also comes to mind.
- Position the repo to target major use cases. They are coming up all the time now but the reponse is always to ignore CoreRT and use some other method. You can't do all of these straight away but the difference between supporting one of these on none of them is life or death for CoreRT.
- WPF. If CoreRT can be used for WPF apps that would get a lot of usage.
- Xamarin. Mono has a lot of compatibility and extends the reach of .Net (into Xamarin.IOS, Xamarin.Android). It would be much better for users if Xamarin and wasm/blazor could use CoreRT instead of Mono AOT.
- Asp.net core. "Simple apps". This needs to be upgraded.
I do think that once you can say with confidence "Now we support full AOT in .NET", you will start attracting a league of programmers that would otherwise not consider .NET.
I agree. While this might be subjective, requiring the user to have interpreters/VMs or shipping them with your products in my opinion feels too low-quality, and while there are ways to provide a seamless experience, decent native binaries would be ideal. The ones CoreRT produce are in my opinion quite good.
CoreRT has been serving me well so far, but I'm a bit disappointed after reading the replies here. It's initiatives like this that make .NET appealing outside the web/LOB bubble, but I was hoping it would have more focus. For realtime software GC is also a substantial problem.
@RUSshy I don't think the comparison with Go is fair. C# is a much better language and it's still appropriate for our indie games. The new features in C# 7.3 and 8 really helped with optimization and if you go with a DoD approach the GC will probably not be a huge problem. However, I'm starting to think that maybe Jai will happen before CoreRT goes official.
FYI https://twitter.com/coolcsh/status/1110392209814126597
I had to bite my tongue not to respond to that comment because it devalues the work lots of people from the community and from Microsoft put into .NET Native and CoreRT. The fact that Scott didn't respond to Eric's comment says it all: https://twitter.com/ericmellino/status/1110623222641225728. I'm thankful for people who chimed in with their good experiences.
@MichalStrehovsky while I agree, the evauation "CoreRT was never able to run complex .NET code" is almost identical to the evaluations ("Simple apps"; "Hello Tizen"; "Simple C# programs"; "very trivial programs only") in README.md, i.e. on the front page of this repo. Those descriptions, which are years old, badly need updating.
The part of the tweet that upset me was actually "So it wasn’t really .NET." The completeness issues that CoreRT has are not that different from limitations Unity (game engine) has and nobody claims Unity is not .NET.
I just realized this discussion is mostly about building a single binary. I personally don't care about that to be honest. While it would certainly be nice to be able to produce small single native binaries for simple CLI tools, in my opinion what CoreRT currently outputs is already acceptable although certainly not perfect.
What is a bit discouraging about all of this is that it seems there's still too much focus on the web. I think .NET is already a very established and competitive technology there, and I'm not sure whether investing so much on it would change that dramatically, although maybe that's where the financial returns are, I don't know. The vast majority of the C# developers and jobs seem to be related to that (ASP.NET and such).
I would like to see a more diverse user base. For realtime applications for example, besides some XNA diehards (MG/FNA/UV) and Unity there's not much going on*. I suspect that with a fraction of the effort being spent on the web stuff .NET could become substantially more attractive to people doing realtime applications like game/simulations/etc. The new lower-level language features introduced since C# 7 helped a lot, but overall there's still a 'server-grade tech' feel to .NET, what could be remedied with AOT and for realtime applications a more suitable GC too. (I'm talking about objective stuff like requiring runtime environments and JIT/GC pauses)
I'm a game developer and it's widely known that the vast majority of us aren't happy with any language we have so far. I'm pretty sure that's very evident if you have contact with other game developers on social media. @RUSshy knows that very well. I personally picked C# because I like the language a lot and things like the "local GC" and CoreRT gave me hope for the future, but I can't really blame my fellow developers who frown upon .NET.
Anyway, I just think that if MS could focus just a little bit more on those issues I mentioned, I'm pretty sure there's a lot of users who would be happy to switch to .NET. It's obvious .NET isn't popular for realtime application development (as it could be), and diversifying the user base is a good thing! However, judging by what happened to XNA it seems that's not a concern, and that makes me a bit wary about the future.
As I said though, CoreRT has been serving me well and I'm planning to continue using it. This is a fantastic project and I'm happy to hear it's not 'dying' as that tweet suggests. I would like to see more focus on the features that matter to me and I feel very underrepresented in the .NET scene. But then again, as I said the money is probably elsewhere (web/LOB) so I can't really complain.
* there are incredible projects like @mellinoe's repos, I don't want to be unfair here, but overall it's clear that there was a huge decline since XNA was discontinued.
@charlesroddie Thank you for the feedback. We will get the status on the front page updated.
Mono has a lot of compatibility and extends the reach of .Net (into Xamarin.IOS, Xamarin.Android). It would be much better for users if Xamarin and wasm/blazor could use CoreRT instead of Mono AOT.
Could you please elaborate on where it would be better from your point of view?
@RUSshy
CoreRT is the way to go, even if slow compilation is annoying, microsoft is making yet another mistake by not focusing on it
I couldn't agree more.
Any discussion on this subject ought to begin by acknowledging a few principles that ought to be obvious but are rarely explicitly mentioned out loud:
- JIT compilation shortens the Edit-Compile-Test loop, making it good for developer productivity.
- JIT compilation it adds a measurable amount to the startup time and imposes a certain runtime overhead. To provide a good experience at getting the software up and running quickly, it necessarily focuses on speed as the highest priority.
- Code optimization frequently takes a non-trivial amount of CPU work (ie. time) to accomplish. Therefore, high levels of optimization are anathema to a JIT.
- Release builds are built much less frequently than development builds, and run much more frequently. (Each given dev build might be run by the developer a few dozen times at most before he makes some change and rebuilds, but a release is sent out to many people and run hundreds or thousands of times.)
- Performance matters far more for a release than for a dev build. Low startup times and high optimization are important.
- Therefore, a JIT is useful for developers, but the exact opposite of what you want when deploying software.
CoreRT should be a standard piece of every .NET Core developer's toolbox. It should be the thing you build your releases against, and it should get a nice, powerful, slow-but-worth-it optimizing compiler instead of the crappy-by-design RyuJIT which is forced to be bad at optimization because it's a JIT.
And while we're on the subject, it should also have RyuJIT or similar as part of the runtime. Pretty much all of these problems we see of things that don't run right on CoreRT because it's AOT and doesn't have a JIT would go away if we just shifted the paradigm a little and instead it was AOT and also has a JIT for when that's necessary. (And if that means poor support for a certain platform designed by a bunch of iDiots and control freaks who can't bear to let the unwashed masses bring a JIT into their pwecious walled garden, then so be it. They've been losing market share for years anyway; why should we care about supporting them when they're actively hostile to our way of doing things?)
@masonwheeler
And while we're on the subject, it should also have RyuJIT or similar as part of the runtime.
At that point, aren't you basically talking about crossgen? Currently it doesn't have good tooling and I believe it also uses RyuJIT, but I think those caveats still leave it in a better place than your suggestion of CoreRT AOT + JIT.
crossgen? Currently it doesn't have good tooling
That is getting fixed for .NET Core 3.0 (see https://github.com/dotnet/sdk/pull/2997).
At that point, aren't you basically talking about crossgen?
Yep, there are many options in the spectrum of AOT/single-file solutions. Today, part of the spectrum is covered by CoreCLR tech, part is covered by CoreRT tech, part is covered by Mono tech, and there are many gaps. We would like to get a continuum instead where you can easily get any configuration imaginable. Sharing and unification between all actively developed .NET Runtimes is our strategy to get there.
I love idea to compile .NET Application to Native code, it so cool !! I will be able to switch from C++ -> C# on embedded chips with RAM less than 128kB ...
CoreRT is the way to go, even if slow compilation is annoying, microsoft is making yet another mistake by not focusing on it
I am agree with this statement !! It is huge mistake and great lost for whole community ... (
Some of you all are acting like CoreRT isn't receiving development anymore. It's pretty clear that it's still actively being developed. These things take time, Rome wasn't built in a day and neither was CoreRT.
Whoops, that's what I get for trusting stale memories. Removed that part of my comment, but the rest of it still stands.
I agree we need strong AOT to deploy applications. The competition is not Java. The competition is Go and Rust both have stronger concurrency for example but C# is better for development its better language than Go and better to develope with better tools than Rust but final product is not good compared to both.
I try contact but no private mesage in githug
@troll-kadabra but that's exactly the point I made... maybe from a purely financial perspective Java is the competition. Maybe Microsoft didn't have the expected outcome from XNA and that's why they dropped it and learned their lesson, that they should try competing on the web instead.
As I said on Gitter: don't wait for them, if C#/.NET isn't suitable for you, then by all means go for another tech. Rust seems to be getting some traction for games these days, many C++ devs are either switching or evaluating it (and most seem to like it). As you said though, C# is much better in terms of iteration times and these days C# is very different from what it was when XNA was around, the latest 'low level' features allow you to code on a whole different level, and XNA was never very performant to begin with.
If you're looking for a language that's more future-proof I'd totally go with Rust, not only the ownership model is probably going to be the new "standard" (so even if Rust itself doesn't quite make it, you'll at least be familiar with the memory management), but as you said concurrency is much better because it was made with that in mind too. Jai won't have those features, but it might very well be an alternative for C# because the appeal is basically the same: faster iteration in a nice but familiar language, but it's not fundamentally modern.
Microsoft's goal is to make money, that might or might not be aligned with your goals and expectations, I'm recently coming to the conclusion that their direction is diverging too much from my expectations. C# 7.3 is already a pretty decent language, nullables would be nice but most of the new features in C# 8 people are talking about are completely passable like ??=, interface implementations, and is not. They are adding those features to the language and improving web/servers stuff while AOT is being overlooked, so their priorities are completely different than mine. Imho .NET is good enough as it is, I just need to ship higher quality products using it.
@Alan-FGR Last I heard about Rust, it was essentially impossible to build a modern GUI application in it because some arcane detail of its memory model made it impossible to store a mutable reference to a UI widget on the heap or something like that. (It's been a while since I read the relevant research; I don't remember the exact details.)
This was about a year ago. Do you know what I'm talking about, and has that been fixed since then? Because until it is, Rust is nowhere near mature enough to be considered as real competition.
@Alan-FGR
They are adding those features to the language and improving web/servers stuff while AOT is being overlooked, so their priorities are completely different than mine.
Keep in mind that you're talking about separate teams. So saying something like "if we didn't have default interface methods, we could have had records" does make sense, "if we didn't have DIM, we could have had AOT" makes much less sense. (Of course MS can decide to move resources between teams, but that tends to be a slow process, because it usually involves recruitment and training.)
Also, ??= and is not are fairly small features, the resources spent on them likely wouldn't have moved AOT by much.
@masonwheeler I've tried Rust many times in the last decade and always ended up rage quitting because I felt like I was fighting the ownership model all the time and the tools are not good, there's no decent linter (very important for Rust) or refactoring tools for example.
However, since it really seems to be getting some traction in the gamedev scene, I recently started giving Rust a real chance. No high expectations, I'm just trying to get used to it in order to have it as an option in my toolbox because it might be useful someday. So I'm slowly but surely wrapping my head around its "arcane" ownership model, and while I still can't say whether It'll ever feel natural and be productive, I guarantee you that you can achieve anything with it, the problem is you have to basically forget all the architectures/patterns you've used in the past. Also, even if you reach a point where you can't somehow shoehorn your code in, you can always use smart pointers and go unsafe.
That being said, it's possible I'll give up once again, maybe my resilience is just because in small daily doses the pain inflicted by Rust is tolerable, but once I really start using it for anything serious I'll conclude it's simply not worth the mental overhead. But again, it's certainly not going to be because it was impossible to do something in Rust. It might be impossible to directly port C++ code to Rust, but you can achieve anything with it, you just have to approach everything very differently from the get go. If you have any links about that issue please let me know. The ownership model is basically the same since the early days afaik.
@svick you're absolutely right, but I'm talking about the grand scheme of things... that's the current state of .NET: you have these language "features" being added to it like there's no tomorrow, while AOT is being neglected... at that rate the specification is gonna be bigger than C++ (it's already close in page count) and we still won't have reliable AOT.
Mono has a lot of compatibility and extends the reach of .Net (into Xamarin.IOS, Xamarin.Android). It would be much better for users if Xamarin and wasm/blazor could use CoreRT instead of Mono AOT.
@jkotas Could you please elaborate on where it would be better from your point of view?
Historically mono, while an impressive cross-platform effort, was much slower and buggier than .Net framework, from all the reviews and benchmarks I have seen. I don't know how much this has changed over the last couple of years, but I suspect that it is responsible for a lot of reported Xamarin slowness.
While there is a strategy to bring mono closer to .Net Core, and a lot of code is being copied over, they are doing this in a selective way without breaking changes, and they are adding features at the same time. Too half-hearted in my view. The .Net Framework has been decisively depreciated and WPF moved to .Net Core. I think Xamarin should bite the bullet and do the same.
Some of you all are acting like CoreRT isn't receiving development anymore. It's pretty clear that it's still actively being developed. These things take time, Rome wasn't built in a day and neither was CoreRT.
It receives development efforts, but how much ... It is possible to make effort in both direction C# Language evolution and AOT simultaneously
I love idea to compile .NET Application to Native code, it so cool !! I will be able to switch from C++ -> C# on embedded chips with RAM less than 128kB ...
CoreRT is the way to go, even if slow compilation is annoying, microsoft is making yet another mistake by not focusing on it
I am agree with this statement !! It is huge mistake and great lost for whole community ... (
you can try : nanoframework、micro framework、or Rust embeded. the corert team never consider MCU!!
I love idea to compile .NET Application to Native code, it so cool !! I will be able to switch from C++ -> C# on embedded chips with RAM less than 128kB ...
CoreRT is the way to go, even if slow compilation is annoying, microsoft is making yet another mistake by not focusing on it
I am agree with this statement !! It is huge mistake and great lost for whole community ... (
you can try : nanoframework、micro framework、or Rust embeded. the corert team never consider MCU!!
https://github.com/MichalStrehovsky/zerosharp I think corert team has opinion to spread it on MCU。
@jkotas And there is an old saying，“If you try to be the best，you will be excellent”（“法乎其上，得乎其中），in other words，if you try to make C# run well on MCU，at least you can have excellent performance on PC without C++. My opinion is not to let you work harder—— I can't represent corert team to decide something， however I will make corert better in the near future.
With the announcements of .NET 5 can someone summarize what this means for this project? The announcement makes it seem like Microsoft are specifically focusing on Mono AOT technologies over this project going forward.
