[Question] CoreRT future plans #7200
Comments
|
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.
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. |
|
Hi Jan, Thank you so much for your answer, I really appreciate it.
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. 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:
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:
|
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. |
|
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. |
|
I'm with you @MichalStrehovsky |
|
More love for corert! |
|
@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'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.
|
|
@charlesroddie Thank you for the feedback. We will get the status on the front page updated.
Could you please elaborate on where it would be better from your point of view? |
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:
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?) |
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. |
That is getting fixed for .NET Core 3.0 (see dotnet/sdk#2997).
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 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. |
|
@PathogenDavid actually, llilc was a LLVM JIT, not AOT. |
|
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 |
|
@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. |
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, |
|
@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. |
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. |
It receives development efforts, but how much ... |
you can try : nanoframework、micro framework、or Rust embeded. |
https://github.com/MichalStrehovsky/zerosharp @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++. |
|
One of the primary focuses I personally have being on the Bing.com Frontend team is making our production serving stack more than 95% precompiled. This involves building our MVC Controller to Type mapping at build time for routing. Similarly for parameter binding generating build-time code. And finally having all our dependency injection registrations have a pattern that source-generator can find and we conquer that too. For things like JsonResult I'm hoping System.Text.Json build-time story gets fleshed out then we're in business for a lot of the code. So I definitely think there is room for Kestrel + Routing + Controller Activation + Parameter Binding + Dependency Injection + JSON serialization to be done 100% at build time. My stretch goal is to do all this with reflection turned off, but that might require Kestrel changes. |
Agreed and as long as it's good I don't think there'd be any disagreement. Historically we haven't finished the experience so users are left with trying to figure stuff out by figuring out linking broke their application and filing issues on various projects asking them to
The experience isn't good in any of those platforms to date. It's unpredictable and that's why we've decided to spend the time to help make it more predictable as well as invest in things like source generators so there's actually a chance for it to be broadly acceptable in the .NET ecosystem. We could choose to do nothing here and leave this tech for power users who are willing to spend the cycles to figure out why stuff got linked out of their binary. I'm speaking about this as a library author that works on a product that works in the places where IL linkers run and people report bugs (SignalR + Unity). It's maddening to have bugs filed without real understanding on how to fix them or maintain those fixes.
Yea I don't really mind options for power users, we always need those, I care about everyone else. |
I do not understand why Reflection should be optional !! Injection (ILCode) could be made optionally, it could be enabled or disabled within some compile flag |
Yep, that's exactly how .NET Native and CoreRT implement reflection. And because it's just an additional side table, the compiler makes it optional (you can turn it off and all non-reflection code still works). The additional tables are enabled by default; there's just an option to turn them off. We're not trying to get rid of reflection, just to give more options to people. |
If nobody is rewriting them, then presumably nobody will be recompiling them either so that scenario can probably be set to the side. For those who want to get improvements an additional profile on the .Net API Analyzer would probably get you 95% there. We have had to deal with these incomplete API's for years on Core so it's hard to see that as a deal breaker.
Is there any commitment on which API's will be adapted to have Source Generator paths? The announcement literature showed ASP.Net scenarios, so can we count on some popular high level frameworks being updated? What about low level reflection dependencies like the generic constraint you mentioned earlier in the thread? Will MS accept PR's on lower level libraries where the main benefit might be to have a code path without reflection for C#? |
|
I am still nosy, what exactly is the roadmap for UWP? I heard @stevenbrix saying
But moving to .NET Core 5 and WinUI3 has the smack of targeting desktop environment only. Is my gut feeling right? Is there any details on how UWP will aligned? For instance, can I still target @MichalStrehovsky Any chance we can use CoreRT instead of .NET Native for UWP in the future and getting this also published to the store? Are there any resources on how to compile UWP with CoreRT instead of .NET Native? And could this be a valid option at all, since this would mean in its consequence using an experimental runtime and the store needs to accept that either. |
|
Just a fair warning: Don't expect the new source generators feature to be too useful. If you read the article the Roslyn folks wrote about it, you'll see they've deliberately crippled it by leaving out some of the most powerful features that you'd expect from metaprogramming, the things it can do, it doesn't do particularly well. (Their introductory sample is done with a From conversations elsewhere, this appears to have been done to better serve the needs of the IDE: make metaprogramming too powerful and it becomes possible to write code that will take a non-trivial amount of time to run, which can cause Intellisense to lag. However, according to the article, generators don't work with Intellisense at all, so...yeah. Don't get your hopes up too high for source generators. |
Sorry, I see how that statement is a bit confusing. I meant there will not be path forward for using .net native and WinUI3. Although, these plans can change based on customer feedback. If we move UWP onto .net5, then the store restrictions will be lifted. We want to move off .net native because it's no longer being invested in, and we want to better align with the rest of the .net ecosystem. Whether this happens in the WinUI3 time-frame, or we have to wait for Project Reunion to be further along, is one that we're still assessing. |
Quasiquoting and better AST generation APIs can always be added later on. What's useful with source generators is making way for it in the actual compiler pipeline so that there's something there at all and we don't have to put together ugly hacks that can never be supported because they are ugly hacks. Source generators are also definitely intended to be able to track changes you make in the code as you make them - you can opt into doing that during the initialization of the generator, and will be fed events by the design-time services (in other words, the Intellisense-backing ongoing compilation). It's not the all-out system I personally would have wanted, and in the beginning you have to bring a lot of pieces to get productive, but imagine how things will look when this infrastructure has been built up after a while, and after more features have been added over the next few versions. Starting from what we have, it's cause for celebration, and it's definitely better than not doing anything at all because of the belief that it's all-or-nothing and all is either way too much work or "not C#-y" ("we don't want macros"). I'll take all the metaprogramming I can get. That said, if you're expecting automatically compile-time-ized reflection (and some press coverage has been confused on this point): that really isn't the case. Don't expect a house when you're being given a hammer, but you can do a whole lot with a hammer. |
It sounds reasonable ... If developer do not use reflection would be possible to remove overhead completely ... |
|
With Mono being rolled in to .Net 5.0 will CoreRT be deprecated in favor of Mono's AOT? |
|
@steskalja We really hope not, because the CoreRT technology is far better than Mono's AOT. That's a large part of the point of this thread. |
|
I don't understand this kind of move by Microsoft, why would they favor such an inferior project and even put it out there in the spotlight of .NET 5? Who makes these decisions nowadays? I really hope it's not just businessmen. |
|
Mono's AOT is ready, with working reflection on iOS. Xamarin also uses Mono's native interop, so even if CoreRT hit stable with reflection via interpreter running on all of Mono's targets, Microsoft would still need to keep Mono around until Xamarin was ported. Supporting both at once sounds painful, so it's not that weird for them to prefer supporting the product that is already in use. |
|
@lmcdougald CoreRT does reflection pretty much on par with mono without interpreter (except for compiled |
|
@GTANAdam I don't think that's business man. The dotnet team have devs whose experience is more into web development in general. (as is, I think, most devs in C# and everywhere) |
Mono being rolled in to .Net 5.0? |
@GTANAdam what? decisions? which decisions? do you think there's someone making decisions? oh man, I really miss Steve Ballmer... |
|
I have just enabled AOT on Android (via startup tracking with a custom profile), and I'm disappointed. It makes the application significantly bigger, instead of smaller as you would expect. Startup time did improve but is still worse then I expected at almost 2 seconds. This is a relatively simple app, no use of Reflection.Emit and very little application code in the startup path. We need CoreRT on Android. Mono AOT just doesn't cut it. |
|
We have created survey to help us shape the future of native AOT: #8256 |
When are we getting results for this survey? I want to use CoreRT in my project, but due to not having official support for it, I didn't get approval for using CoreRT. |
|
@preetiarora89 You will find first results here: dotnet/runtime#41522 |
|
We have moved bulk of the project to a new place in https://github.com/dotnet/runtimelab. This repo is going to be archived at the end of the month. #8366 has more details and discussion about the plan. |
and others
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.
The text was updated successfully, but these errors were encountered: