search

dotnet / corert

This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
http://dot.net
MIT License
2.91k stars 510 forks source link

[Question] CoreRT future plans #7200

Open christianscheuer opened 5 years ago

christianscheuer commented 5 years ago

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.

jkotas commented 5 years ago

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

christianscheuer commented 5 years ago

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!

charlesroddie commented 5 years ago

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:

Alan-FGR commented 5 years ago

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.

MarcoRossignoli commented 5 years ago

FYI https://twitter.com/coolcsh/status/1110392209814126597

MichalStrehovsky commented 5 years ago

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.

MarcoRossignoli commented 5 years ago

I'm with you @MichalStrehovsky

mhmd-azeez commented 5 years ago

More love for corert!

charlesroddie commented 5 years ago

@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.

MichalStrehovsky commented 5 years ago

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.

Alan-FGR commented 5 years ago

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.

jkotas commented 5 years ago

@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?

masonwheeler commented 5 years ago

@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:

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?)

svick commented 5 years ago

@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.

jkotas commented 5 years ago

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.

redradist commented 5 years ago

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 ... (

PathogenDavid commented 5 years ago

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.

Suchiman commented 5 years ago

@PathogenDavid actually, llilc was a LLVM JIT, not AOT.

PathogenDavid commented 5 years ago

Whoops, that's what I get for trusting stale memories. Removed that part of my comment, but the rest of it still stands.

troll-kadabra commented 5 years ago

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

Alan-FGR commented 5 years ago

@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.

masonwheeler commented 5 years ago

@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.

svick commented 5 years ago

@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.

Alan-FGR commented 5 years ago

@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.

charlesroddie commented 5 years ago

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.

redradist commented 5 years ago

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

snikeguo commented 5 years ago

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!!

forestbat commented 5 years ago

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.

ourplan9000 commented 5 years ago

More love for corert!

blanchet4forte commented 5 years ago

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.

charlesroddie commented 5 years ago

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.

trampster commented 5 years ago

Just read the .net 5 announcement and it's all Mono AOT, corert was not even mentioned.

jeswin commented 5 years ago

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.

forestbat commented 5 years ago

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.

govert commented 5 years ago

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?

filipnavara commented 5 years ago

I think MonoAOT will be changed to use CoreRT

Nope. There's shared code for System.Private.CoreLib.dll but not much else.

filipnavara commented 5 years ago

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.

MichalStrehovsky commented 5 years ago

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.

valeriob commented 5 years ago

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 ?

tonerdo commented 5 years ago

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

loic-sharma commented 5 years ago

@tonerdo Please do! It is much easier to prototype crazy ideas on a runtime that’s written in C#.

charlesroddie commented 5 years ago

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.

tonerdo commented 5 years ago

@MichalStrehovsky what's the story with .NET Native? Where does it fit into all this?

Lexcess commented 5 years ago

@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.

filipnavara commented 5 years ago

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.

filipnavara commented 5 years ago

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.

filipnavara commented 5 years ago

GitHub implemented a time machine now :-/

image

MichalStrehovsky commented 5 years ago

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.

filipnavara commented 5 years ago

@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.

troll-kadabra commented 5 years ago

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