search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.98k stars 4.66k forks source link

Survey: Native AOT [results] #41522

Closed jeffschwMSFT closed 3 years ago

jeffschwMSFT commented 4 years ago

Thank you for responding to our .NET Native AOT survey (https://github.com/dotnet/runtime/issues/40430)! We had over 1,400 responses. We are in the process of analyzing results and will soon start to reach out for specific follow-up. Nearly a quarter of the respondents provided their contact information. Thank you! Given the large number of responses, we will not be able to follow-up with everyone. We included some of our analysis and follow-up questions below, let’s keep the discussion happening on this thread. Here are the raw aggregated results.

Which of the following languages do you primarily use to complete day to day work?

image Follow-up questions:

What have you done in CoreRT (experimental project)?

image Follow-up questions:

Overall, how satisfied or dissatisfied are you with CoreRT?

image Shout out to the dotnet/corert contributors that completed the survey – thank you for your contributions.

What, if anything, do you find frustrating or unappealing about CoreRT?

image Lack of official support came through loud and clear. In addition, there was significant feedback around the lack of onboarding process and the complexity of dealing with Reflection. Follow-up questions:

Why do you use a native AOT technology?

image Follow-up questions:

Does the lack of officially supported native AOT option prevent you from using .NET more?

image

Because of the missing native AOT option, what environment(s) do you use instead?

image

If you had/have AOT as an option, which workload(s) would you want to use?

image The survey contained a rich set of insight into GUI and Games development – thank you! Follow-up questions:

Which GUI(s) do you work with?

image image

Which of these tasks are a part of your production debugging workflow?

image

Which of the following best describes your primary role or work environment at your organization?

image

Dotnet-GitSync-Bot commented 4 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Symbai commented 4 years ago

No JIT and obfuscation on the last places. I wonder if this will boost readytorun or GAC approach rather than a true native solution I personally has hoped for? At least GUI and WPF on the upper places, so there is a chance for AOT with WPF and not AOT with console / MAUI / Xamarin.Forms only.

I'm really curios what we will get in the end and how the community reacts to it. It turned out there are many different wishes and views on AOT. So please keep us informed about this topic. And huge thanks for giving us the result of this survey ❤

SingleAccretion commented 4 years ago

One thing that I feel would improve the AOT story (and make using CoreRT much easier) for .NET a lot is a way to tell whether your app/library is AOT-friendly and is guaranteed to not blow up at runtime on some random Type.GetType. The linker attributes are a huge step towards that and it feels important to me that we market them not just as "make your library Blazor-friendly", but "make your library Blazor-and-CoreRT-and-iOS-friendly".

vcsjones commented 4 years ago

Thank you very much for publishing these results! I do have a request, which is perhaps the data could be shared as a public (read only) Excel Office 365 document, complete with all of the charts. I'm not really asking for raw response data, just enough table data that was used to make the charts in the first place.

The reason I ask is because I am struggling to read the text in the images. My vision is Pretty Darn Bad and I use a lot of zooming, large fonts, and accessibility controls to read. Maybe this screenshot will illustrate the image text against the large text of the GitHub post that I can read well.

This isn't anything I can't deal with right now, so no worries, but perhaps something to consider for the next time (and I hope there is a next time!)

image

jeffschwMSFT commented 4 years ago

Something may have been lost when I cut&pasted. Trying that chart again.

image

srxqds commented 4 years ago

we are embedding mono runtime, so we hope the mono aot can be continuous iteration and optimization

atotalnoob commented 4 years ago

I value smaller docker runtimes, a lot. Being able to compile to native would remove a very large portion of our current docker images.

davidfowl commented 4 years ago

I value smaller docker runtimes, a lot. Being able to compile to native would remove a very large portion of our current docker images.

Trimming without AOT would remove a very large portion of your current docker images.

prajaybasu commented 4 years ago

I value smaller docker runtimes, a lot. Being able to compile to native would remove a very large portion of our current docker images.

Trimming without AOT would remove a very large portion of your current docker images.

Most scenarios that would benefit from smaller docker images also benefit from faster startup. So that's a compromise compared to CoreRT.

Also, the AOT generated code in R2R is equivalent to Quick JIT, right? Wouldn't R2R generating Tier 1 code be closer to "real" AOT?

reflectronic commented 4 years ago

Wouldn't R2R generating Tier 1 code be closer to "real" AOT?

Crossgen does generate "Tier 1" code. However, there are certain limitations on optimizations that can be made (for example, methods cannot be inlined between assemblies). Thus, while it still has most optimizations on, it is considered "Tier 0" in the sense that it can be recompiled later for better performance. Crossgen2 improves many of those types of scenarios (see the version bubbles design document).

pjmlp commented 4 years ago

Thanks for the survey, regarding some of the follow up questions.

I don't see why a distinction is required for F#, the selling premise of Common Language Runtime was being a polyglot runtime, leaving out F# of .NET Native was a big mistake for language adoption. Any decision that makes it into the C# Language Runtime is one less reason to bother with anything else.

Ironically this is one area where JVM/GraalVM is doing better than .NET, although it was designed just with Java in mind.

What I am missing is a Delphi/Eiffel like development experience for any kind of scenario, no constraints.

No experience with CoreRT, as it was always sold as experimental, some experience with .NET Native, which I was relatively happy with, until the current roadmap which seems to throttle back to Windows 7 Dec tooling and pretend WinRT never happened.

How does lack of AOT hinders my work? Microsoft itself, by forcing Windows developers to also mess with C++ for scenarios where the internal politics seem to be "no .NET here please". For example Longhorn ideals, versus rebooting them via COM and later UWP. Or having WinUI, Win2D, DirectX favouring C++ over anything else.

Meanwhile other platforms allow us to enjoy the productivity of AOT managed languages without dropping into C++, e.g. Swift with Metal, macOS drivers in Swift....

pjmlp commented 4 years ago

@RUSshy there is an alternative, to ignore .NET for AOT scenarios and just use any upcoming language with a solid AOT story, despite tooling shortcomings. 20 years ago .NET was also a baby ecosystem with similar shortcomings in adoption.

Maybe that way Microsoft management will get the message where to spend its resources, instead of yet another UWP reboot.

bruno-garcia commented 4 years ago

If you build native libraries with native AOT, is there a specific set of calling languages that you support / cater to?

Rust and Dart. But a supported/stable story for building AOT libraries and exposing a C ABI would already be great.

Which of these tasks are a part of your production debugging workflow?

Please account for proper Error Tracking tools like Sentry?

RalfKornmannEnvision commented 4 years ago
  • What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?

In general every platform that is used for games. But the most pressing onces are game consoles and the web browser as they are lacking the most when it comes to a good C#/.net development story

  • For the games scenarios, do you just need Native AOT, or are there other parts of .NET that you would want improved to satisfy the requirements you have?

For the windows platform official bindings for game apis like DirectX would be nice. The community is able to provide these so far. But without official bindings we C#/.net developers always fell a little bit left behind when it comes to game development. Sure to get the most out of a system someone might need to go more down to the metal. But there are many great game ideas that might not require to squeeze anything out of the hardware. In these cases it's more a question about how much time and money would be needed to develop these games that decides if they are ever made.

It would be nice if we could have something similar like Xamarin for game consoles. Something that allows use to use C# instead of C++ to develop games but without an high level abstraction like unity. Basically a .Net runtime with the BCL and managed bindings for the custom system apis and some Visual Studio templates as staring point. I understand that this is a complicated issue as it involves NDAs and Microsoft is with the different XBox systems in competition with other game consoles.

Beside of the DLLImport a way to do a static import would be nice. Heaving a way to Implement some critical code in C/C++ or even assembler could be helpful. It can be dome with DLLImport but having these small code sections directly in one executable would make things more convenient. 

We would appreciate an incremental GC. Setting away a fixed amount of time and CPU cores every frame to let the GC doing some parts of the cleanup. This would make it much easier to get steady frame rates. It would be acceptable if we need to pay with an higher overhead for this mode as long as it can be used to avoid spikes. In cases the game is just producing to much garbage running regulars GCs would be fine. It's possible to reduce garbage to some point but going to zero garbage is most times just too much work. Therefore an incremental GC could provide a nice sweet spot here.

Jure-BB commented 4 years ago

For the games scenarios, do you just need Native AOT, or are there other parts of .NET that you would want improved to satisfy the requirements you have?

RalfKornmann's post above sums it pretty well. Without repeating too much, I wish to emphasize that low max latency per frame is essential in games. Anything related to memory management and GC that would help reduce max latency would be much appreciated. Currently, the only solution to avoid GC spikes, is to not allocate anything on the heap during gameplay, which is quite limiting and sometimes borderline impossible.

Another useful thing would be deterministic cross-platform floating point arithmetics.

Kryptos-FR commented 4 years ago

For the windows platform official bindings for game apis like DirectX would be nice.

For DirectX there was https://github.com/sharpdx/SharpDX, but maintenance was stopped for various reasons. That's the kind of project that should have been taken custody by the DirectX team at Microsoft, and/or the dot net foundation (with official support from Microsoft).

Games are how I was introduced to .NET/C# (with Unity and Monogame). And I guess a lot of people have a similar story. Therefore, I believe it should be first-class in .NET ecosystem (esp. AOT).

RalfKornmannEnvision commented 4 years ago

For DirectX there was https://github.com/sharpdx/SharpDX, but maintenance was stopped for various reasons. That's the kind of project that should have been taken custody by the DirectX team at Microsoft, and/or the dot net foundation (with official support from Microsoft).

I am aware of SharpDX as I used it in different projects. But as you said it's not official.  A long long time ago (back in the days when I still was a DirectX MVP) there was an official binding called managed DirectX (or short MDX) which than became XNA. But both are deprecated today.

Monogames is kind of the successor of XNA.

john-h-k commented 4 years ago

I am aware of SharpDX as I used it in different projects. But as you said it's not official.  A long long time ago (back in the days when I still was a DirectX MVP) there was an official binding called managed DirectX (or short MDX) which than became XNA. But both are deprecated today.

There's https://github.com/terrafx/terrafx.interop.windows , which provides raw 1:1 bindings for all of DX11 and 12. It's effectively just the C# version of d3d12.h (rather than an attempt to C#-ify DX, like SharpDX does).

Perksey commented 4 years ago

CoreRT presents an immense opportunity for Ultz, our internal projects that are looking for a suitable and supported AOT technology, and our Silk.NET project.

Our primary discipline is game development, however as you can imagine the .NET ecosystem is currently lacking a rich set of tools to target game consoles and mobile platforms (sure, Mono, but MonoAOT isn't nearly as much of a leap forward as CoreRT is, and I strongly believe that CoreRT is the future of .NET's portability)

We've heard from Silk.NET users that CoreRT support would massively benefit graphics and games development, and one user has even gone as far to fork CoreRT and implement the necessary support for some consoles. As a response, we currently have a working Silk.NET + CoreRT example (thanks @HurricanKai) sitting in review and the results are very promising.

All in all, CoreRT presents an amazing opportunity for C# and the .NET ecosystem, and could very likely present C# as a viable option for workloads .NET is otherwise be unsuitable for today.

And now for the follow-up questions:

No support for System.Reflection.Emit was a hard boulder to overcome, but to be honest support for that isn't important at all for an AOT platform anyway. We ended up rewriting the library in no small way to make it AOT friendly (which, to be honest, we were gonna do anyway). After that, apart from some reflection hiccups which could be fixed by flipping some switches in the csproj (which should probably be enabled by default to reduce surprises?), we successfuly got the example running. The startup performance of CoreRT is tremendous, and the possibility of using CoreRT to port our games to various other platforms is exciting.

HurricanKai commented 4 years ago

If CoreRT would get Mobile support that leaves everything to the application that would be huge. I've not seen such efforts until now, unfortunately.

Perksey commented 4 years ago

cc @Deecellar

Deecellar commented 4 years ago

I love CoreRT is a neat project, and it's pretty much what I have been working figuring out how to implement backends, it's a shame it's so damn dificult sometimes to navigate and work with (IMHO).

Also I would like easier to implement backends in general (Docs =>), thanks <3

HurricanKai commented 4 years ago

In my experience so far, almost all reflection we use can be replaced by source generators. Right now I'm working on replacing dynamic assembly loading, which proves to be rather difficult and in my opinion should be a CoreRT feature.

yowl commented 4 years ago
develooper1994 commented 4 years ago

compiled application size is still very big for blazor client(wasm). I am looking for much more elimination like c++ compliers do.

Other way is the reflex dotnet into a c/c++. Unity has complier IL2CPP.

sgf commented 4 years ago

What age is it now? What kind of investigation are you doing for things like native? Things that should have gone all out long ago. This matter is already 20 years late.

swordday commented 3 years ago
jtbrower commented 3 years ago

Thank you for the survey results. I am happy to see Avalonia high up on the list because I decided to select it over WinUI to upgrade a rather large WPF app into after seeing WinUI fall short of the goalpost at this time.

Compared to WPF, I am seeing faster performance, smaller binary sizes and less overall memory consumption for the first usecase that I put Avalonia through.

I actually happened upon this survey when I realized for the first time that ReadyToRun did not provide full AOT! That was a big surprise to me because I have been locked in pre-production development phases that until comparing Avalonia performance, I had no clue it wasn't fully native. So add my enthusiasm for full AOT! I now wonder how I was "misled" to believe ReadyToRun was anything but full native. Now I know!

sgf commented 3 years ago

here is a native language,and its very like C#.

The syntax and many semantics are most directly derived from C#

Its name is Beef. https://github.com/beefytech/Beef If capable developers can submit code and contribute to the project. You can enjoy the advantages of a real true native-language.

Not just like .net Team's AOT. AOT is not realy Native. and microsoft's C# Native progress is too slow. Now you don't need to wait for several years for native Features (i belive u are wait too many years).

pjmlp commented 3 years ago

@sgf Another one is D, this is what .NET 1.0 / C# should have been like.

sgf commented 3 years ago

@sgf Another one is D, this is what .NET 1.0 / C# should have been like.

I used to look forward to the D language very much, but for many years, the development of the D language has been slow, and the D language development tools are very bad and unstable. The D language community is too closed. Even register a separate forum account for raising an issue. The Api design style of D language is closer to C/C++ , not very similar to C#.Of course I know that D1.0 used to be very good. But now version 2.0, I have almost lost interest.

sgf commented 3 years ago

I'm the opposite as you, i lost complete interest in C#

im not lost complete interest in C# C# is still my main language. Just because I have been trying to use C# instead of C/C++, and C# can’t do it. This is frustrating. Therefore, in the Native scenario, I strongly hope to find a replacement for C#.

d The language is good in some aspects, but I still can’t like it. As I mentioned above, the style of D language and class library style is not very similar to C#. Until I recently know Beef, a lot of code was ported directly from C# code. There is even more than 80%+ compatibility in syntax.

sgf commented 3 years ago

https://marketplace.visualstudio.com/items?itemName=LaurentTreguier.vscode-dls works

I have tried any Dlang plugin(for VSCode,for VS).all of them.

They are not complete enough. And it is not stable enough. Only basic functions. I have some experience using golang. As early as 2015, golang's development tools have done a good job(LiteIDE,VSCODE). But now is 2020. I have waited for several years, and Dlang's tools still cannot reach the level of golang tools five years ago.

Perksey commented 3 years ago

Let's not forget this is a C# thread people :P

pjmlp commented 3 years ago

Let's not forget this is a C# thread people :P

It surely is, but Microsoft needs to be made aware that excuses of what AOT actually means, leaving .NET Native in a limbo state and not offering proper alternatives means that we probably will look elsewhere for our AOT deployment scenarios.

It isn't 2000 any longer, there are plenty of languages to chose from with proper native AOT support, not just pseudo AOT like R2R.

HurricanKai commented 3 years ago

R2R isn't advertised or meant as AOT solution, and as you can tell from the results above, > 60% respondents are interested in AOT because of startup times. And that's what R2R is, AOT for startup. Of course it's unfortunate that right now there is no supported full AOT solution, but this is what the Survey is for, to check whether there is significant interest in AOT. So not sure what all these complaints are about.

pjmlp commented 3 years ago

Then just make NGEN cross platform and be done with it.

Perksey commented 3 years ago

It is, it’s called CrossGen

On Wed, 7 Oct 2020 at 11:22, pjmlp notifications@github.com wrote:

Then just make NGEN cross platform and be done with it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/runtime/issues/41522#issuecomment-704842157, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVEYI23MO6WBVGXZGGRJU3SJQ6NBANCNFSM4QOIOKZQ .

DQRC69420 commented 3 years ago

It surely is, but Microsoft needs to be made aware that excuses of what AOT actually means, leaving .NET Native in a limbo state and not offering proper alternatives means that we probably will look elsewhere for our AOT deployment scenarios.

It isn't 2000 any longer, there are plenty of languages to chose from with proper native AOT support, not just pseudo AOT like R2R.

Honestly? I see them still making that same mistake today with the GC. Dont get me wrong I ADORE the GC and how optimized it is. But for certain applications its just not optimized ENOUGH. They could have given us an option to deallocate objects in a seperate heap safely and manually like how it was done in Rust for example.

But instead they're funding projects like Verona...where the main goal is to create a language that has Rust-like abilities!

So according to microsoft, safe manual memory management is something you totally shouldnt use, but its also necessary. That begs the question: why arent we using it when WE need it? Because I've seen many many requests for a safe manual management tool. Even here. Some want a Heap-object you can put your allocated stuff in like a collection where you can also deallocate/remove them, some want an Allocator-object that hides the object from the GC and lets you deallocate whatever you've attached to the allocator, and some people even want to replace the GC with another GC! The demand is clearly there and I cant imagine what I'd do if C# was able to one day not only allow safe manual memory management but also aot! All sorts of programs would be doable.

And hey, when the GC becomes so optimized that it even outperforms good manual management, then they can remove the tool if they want. But as long as GC cannot cover a wide variety of usecases there should be an option to do manual memory management(MMM) imo. Project snowflake was a good start and we shouldnt have to fight the GC just because we prioritize performance. Instead we should work with the GC.

Maybe I'm just dreaming too much idk, but I can only imagine what kinda stuff I'd work on if MMM + aot made it into the main .Net versions.

PathogenDavid commented 3 years ago

like how it was done in Rust for example.

While I do agree a manual memory management escape hatch is an idea worth exploring, Rust's memory management model heavily relies on the concept of borrowing. Adding borrowing to an ecosystem that wasn't designed with it in mind is non-trivial. @jaredpar (the C# compiler team lead) blogged about adding it to C# here: https://blog.paranoidcoding.com/2019/12/02/borrowing.html