[Question] CoreRT future plans
christianscheuer opened this issue · 257 comments
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.
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.
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 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?
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?)
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 dotnet/sdk#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.
@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 ??=, 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.
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.
More love for corert!
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.
It's great that they are merging Mono into .Net Core.
The next step in the strategy (for .Net 5) seems to be: have CoreCLR and Mono as drop-in replacements. This means that CoreCLR and Mono will compete for a while.
Mono has been prioritized for AOT workloads. To have a chance, CoreRT will need to 1. be a drop-in replacement for Mono AOT (which means getting it working in WebAssembly, Blazor, WPF), and 2. improve compatibility (interpreter, JIT) which was the reason for Mono AOT being prioritized. It will need to do this fast. Then it needs to have quantitative info showing superiority over Mono AOT.
Just read the .net 5 announcement and it's all Mono AOT, corert was not even mentioned.
The lack of mention of CoreRT in the announcement is indeed concerning.
I just started a mid-size project based on CoreRT, but now I'm wondering if I should just switch it over to Rust. On one hand there's a phenomenal team working on CoreRT, and on the other such lack of clarity from Microsoft.
I think MonoAOT will be changed to use CoreRT——“MonoAOT” will only be a name，or a “shell”.
This is only my guess，finally we need MS and corert team say something.
The initial .NET 5 messaging cannot be more confusing.
I want to use some .NET technologies to AOT compile c# code into a native .dll that will run on Windows. Currently I can kind of do this with CoreRT and the "NativeCallable" magic from @tonerdo, but it seems an unsupported scenario going forward.
What will be the .NET 5 approach to making an AOT compiled native .dll for Windows?
I think MonoAOT will be changed to use CoreRT
Nope. There's shared code for System.Private.CoreLib.dll but not much else.
Currently I can kind of do this with CoreRT and the "NativeCallable" magic from @tonerdo, but it seems an unsupported scenario going forward.
It was always unsupported scenario to begin with. Nothing changed there. If it works for you then you can continue using it.
Personal opinion, not actually speaking for Microsoft, yadda, yadda.
CoreRT was and still is an experimental project. It has many unique strengths - such as the ability to generate very small self-contained apps, great startup performance, unique compilation modes, or ability to generate real native libraries. These strengths are unmatched by any other .NET runtime and are by itself a reason for CoreRT to exist. CoreRT sets a bar on how fast the fast startup can be, how small the small deployment sizes can be, and how native the native libraries built with it are.
Addition of Mono AOT under the .NET Core umbrella (now ".NET 5") is a great thing, because it will allow using all the .NET Core innovations and APIs on platforms only accessible through Mono (iOS, watchOS, PlayStation, etc.). It's worth stressing that AOT in Mono is not new - it has been invested into and existed for longer than CoreRT. The new thing in the announcement is that Mono will be able to run .NET Core apps - I'm excited by that because it straightens the .NET story - there is just One .NET going forward. Mono does AOT quite differently from how CoreRT does it though (I brush on that here).
When it comes to future investments, CoreRT shares a lot of code with CoreCLR: CoreCLR's RyuJIT is also CoreRT's RyuJIT. CoreCLR's System.Private.CoreLib is also CoreRT's System.Private.CoreLib. Thanks to @Suchiman's work to catch up CoreRT's GC, we might soon be able to say the same about the GC. Thanks to this setup, it's pretty easy to keep CoreRT up-to-date with the latest developments in the One .NET and keep CoreRT part of it. This project fills a niche no other runtime fills at a small fraction of the cost of a separate runtime, since it stands on the shoulders of a giant (CoreCLR). One only needs a couple volunteers to keep CoreRT running and still make nice progress. CoreRT has been actually running in this mode for a while now. My weekend projects will still be CoreRT related, as they have been in the past year or so, because I believe in the project and its merits.
Thanks @MichalStrehovsky nice wrap up !
Can you tell us what are the pros and cons of both CoreRT and MonoAOT ? From what i understand :
CoreRT runs on x64, (Windows, MacOS and Linux)
MonoAOT runs everywhere : webAssembly, x86, x64, ARM, ARM64 (Windows, MacOs, Linux, IOS, Android)
What about performances ? CoreRT seems to set a standard for both Startup time, Binary Size and performances. I guess the only drawbacks of MonoAOT are about performances ?
One only needs a couple volunteers to keep CoreRT running and still make nice progress.
If this is the case, I'm happy to continue work on the CoreRT interpreter
@tonerdo Please do! It is much easier to prototype crazy ideas on a runtime that’s written in C#.
They intend to make Mono and CoreCLR drop-in replacements, which both share CoreFX and thereby the same APIs, justifying the name ".Net 5". This is great.
However I don't believe it will go exactly as planned. The plan suggests that the Mono runtime is going to get more usage as a replacement of CoreCLR, by being the supported AOT route.
I expect the opposite will happen. Unless they can pull off a miracle, no-one will want to drop in Mono AOT to replace CoreCLR. Mono AOT startup time needs to be reduced by about 40% to match CoreCLR, and by 85% to match CoreRT. And performance once running is also much slower.
Instead, users will want to drop in CoreCLR/CoreRT in place of the Mono runtime wherever this is possible.
@MichalStrehovsky what's the story with .NET Native? Where does it fit into all this?
@charlesroddie for CoreRT to be a drop in replacement it would need to have an interpreter (which is at least in progress), fairly significant updates to the toolchain and doubtless many other things. Doesn't sound like a given.
Talking on CoreRT Gitter yesterday it seems like Mono is betting on better LLVM integration to improve performance.
I expect the opposite will happen. Unless they can pull off a miracle, no-one will want to drop in Mono AOT to replace CoreCLR. Mono AOT startup time needs to be reduced by about 40% to match CoreCLR, and by 85% to match CoreRT. And performance once running is also much slower.
While the numbers are impressive they are not necessarily representative of Mono today or Mono in year and half from now. I think the important part of the article is the technical side and the description of the differences and similarities but the numbers don't tell the full story. @MichalStrehovsky didn't say what version of Mono he used for the comparison or whether it was the LLVM-enabled build.
Mono was historically lagging behind in speed compared to CoreCLR and other .NET runtimes. That's changing now. It can use LLVM infrastructure which is much closer match in performance to the other runtimes. This enables advanced optimizations like loop auto-vectorization that not even CoreCLR can do today.
Instead of spending resources on perpetual catch-up on class libraries Mono can now spend more resources on the runtime itself.
That said, I do believe that CoreRT is a good technology that has its place and I am very grateful for all the work people do on it today.
what's the story with .NET Native? Where does it fit into all this?
@tonerdo According to the presentation on Build 2019 it's not going to be used anymore. There were multiple hints dropped by Scott Hunter that said CoreCLR will be used in its place. You can watch the ".NET Today and Tomorrow" session.
GitHub implemented a time machine now :-/
While the numbers are impressive they are not necessarily representative of Mono today or Mono in year and half from now. I think the important part of the article is the technical side and the description of the differences and similarities but the numbers don't tell the full story. @MichalStrehovsky didn't say what version of Mono he used for the comparison or whether it was the LLVM-enabled build.
$ mono --version
Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:09:21 UTC 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(600)
Suspend: hybrid
GC: sgen (concurrent by default)
ASP.NET Startup time with Mono:
| Startup | |
|---|---|
| JIT only | 446 ms |
--aot on *.dll |
326 ms |
--aot --llvm on *.dll |
338 ms |
(Now you can at least see how precise my hand-drawn graphs in the article are - this is from my notes.)
I don't think being able to autovectorize matters much in startup scenarios. I would bet this time is getting spent elsewhere - not actually running user code. (And yes, it's worse with LLVM - I retested this twice.)
The test is here in case you want to retest or use some secret sauce switches: https://github.com/brianrob/tests/tree/master/managed/aspnet_start/src.
@MichalStrehovsky Thanks for posting the details. I didn't mean it to sound like I am accusing you of rigging the benchmarks so sorry if it sounded that way.
Lot of the important work on Mono+LLVM happened after 5.20 and I don't think it reached any public release yet. Maybe some of it will land in 6.2, or even later (6.3 is then current development version as of today).
I don't think the LLVM work will affect the startup time significantly. The .NET Core builds on the other hand will have different performance characteristics for startup time. Lot of the initialization happens differently there (eg. through CoreFX and static constructors instead of hard-wired initialization in the runtime).
I mentioned the auto-vectorization as something where Mono is outperforming CoreCLR. I didn't necessarily mean it in the context of startup time but in the performance as a whole.
It's too early to do any meaningful performance comparisons. Work is done to address these performance concerns and that's the only message I wanted to send along.
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. i dont understand how this 2 projects are not redundant it seems the stuff that doesnt overlap is minimal like making native binaries. the important stuff overlaps a lot so it makes more sense to use the parts that overlap from Mono LLVM i think, if it has more potential
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.
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.
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
Would be great to get some updates on how .NET 5 affects CoreRT project
@yahorsi Doesn't #7200 (comment) answer that?
@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?
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.
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
@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。
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.
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.
@vitorgrs there is native C# for UWP already. But I do not know about Net Core 3 support.
@rolandh yeah, the point is exactly the future of .NET on UWP.
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!
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.
@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.
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
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.
I want __asm in C#
And when you write x86 asm then compile it for ARM what should happen?
@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.
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 What is?
@masonwheeler Weird and random Microsofts' one step forward 2 backwards
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
@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.
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.
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/platformrepository 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.
@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).
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.
@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.
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.
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.
Fantastic news, didn't know about that one. Thanks for the pointer.
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.
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 ;-)
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.
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
@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.
@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.
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!
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
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.
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 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.
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.
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
@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.
@jkotas what do you mean by native AWS support?