Survey: Native AOT [results]

[jeffschwMSFT]

Thank you for responding to our .NET Native AOT survey (#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?

Follow-up questions:

• F# showed up in a number of places in the survey, what kind of F# applications would you like to use with Native AOT?
• Which characteristic or feature of another language/platform would you like to see in a Native AOT solution for .NET.

What have you done in CoreRT (experimental project)?

Follow-up questions:

• Please tell us your success or failure story if you’ve used CoreRT. We are very interested in specific stories of CoreRT’s strengths and limitations, both ones you overcame and did not.
• Were you able to get an application functionally working to your satisfaction, but didn’t deploy it in production for other reasons? If so, what were those reasons?
• What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?

Overall, how satisfied or dissatisfied are you with CoreRT?

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?

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:

• For the aspects of CoreRT that you found most challenging, how much would they need to improve for you to recommend CoreRT to someone else? Please be as specific as possible.
• Is there a comparison to another technology you could make along the lines of “I wish CoreRT was like Rust (for example) in this specific way” that would make you want to use CoreRT more?

Why do you use a native AOT technology?

Follow-up questions:

• We hear from users that some of these characteristics are 100% required and others are more nice-to-have. It would be great to see ordered listed of these characteristics (with a clear call out of the must-have ones) so that we can see clustering of high-value characteristics. Feel free to add characteristics that were not listed in the survey that are important to you.
• If you build native libraries with native AOT, is there a specific set of calling languages that you support / cater to?

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

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

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

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

• Please tell us more about the cloud scenarios you are targeting. If you are using Docker, do you value small container images? How do you achieve that? If you create cloud infrastructure components, do have specific requirements beyond what one would expect for a web application/service?
• 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 embedded scenarios, what are the specifications for the hardware you are targeting? Are these low resource/constrained environments?

Which GUI(s) do you work with?

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

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

[Dotnet-GitSync-Bot]

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]

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]

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]

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

[jeffschwMSFT]

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

[srxqds]

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

[atotalnoob]

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]

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]

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]

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]

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]

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

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]

• 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]

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]

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]

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]

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]

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:

• Please tell us your success or failure story if you’ve used CoreRT. We are very interested in specific stories of CoreRT’s strengths and limitations, both ones you overcame and did not.

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.

• Were you able to get an application functionally working to your satisfaction, but didn’t deploy it in production for other reasons? If so, what were those reasons?
  We're reluctant to deploy any CoreRT-powered applications into production entirely due to the lack of official support. CoreRT has been proven to work in many scenarios and it's shaping up to be a very capable piece of kit, however until Microsoft provides dedicated support and pumps resources into the project, we just don't have no guarantee that development will slow to a halt tomorrow.

• What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?
  x64 and arm64. Platforms: Xbox devices via XDK (x64), Nintendo Switch (arm64), PlayStation 4 (x64), as well as the typical PC workloads.

• Which characteristic or feature of another language/platform would you like to see in a Native AOT solution for .NET.
  An LLVM IR backend would be nice, as even the most exotic platforms often provide an LLVM toolchain. This would increase portability while also decreasing the amount of work the CoreRT team has to put in to support these platforms.

[HurricanKai]

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]

cc @Deecellar

[Deecellar]

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

• Please tell us your success or failure story if you’ve used CoreRT. We are very interested in specific stories of CoreRT’s strengths and limitations, both ones you overcame and did not.
  I am waiting as for right now source generators to work with some aspects on reflection without having 2000 problems with my
  dev machine, really, reflection can be a pain, and source generators, while not offering a full solution to it, working around
  reflection and Emiting IL and stuff is always a pain, even so that I have started working in doing a my own AOT solution using
  LLVM and stuff.

• Were you able to get an application functionally working to your satisfaction, but didn’t deploy it in production for other reasons? If so, what were those reasons?
  I don't deploy things that are experimental or in preview, example of that is an ASP.NET core app I did for a project, I got it to work with coreRT, but if I was to continue with CoreRT could I be able to continue making it work fine? it's too big of a posibility next feature I was gonna implement did not work with coreRT, it's always a gamble when you are working in experimental or previews. (Even tho I like being on bleeding edge)

• What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?
  I work with x64, x86, Arm64, Arm32 and Power PC, even when in Game Dev most of my efforts are into PC, Android and IOS, that also means that my game console stuff is not actually pretty powerfull, I target Xbox and Ps4 but I cannot go with the objective of supporting old platforms (I like to port stuff to old consoles, just for fun), and I am stuck with C++ for those endevours, and I think @Perksey can testify how much I complain on doing C++ stuff.

• Which characteristic or feature of another language/platform would you like to see in a Native AOT solution for .NET.
  I am with people that wants LLVM IR here, it's extremly helpful for a lot of projects, and it would reduce the amount of work it's needed to port to a new platform (still a lot, but we can rely on other people work and not doing it again).

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

[HurricanKai]

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.

[develooper1994]

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]

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]

• What platforms (eg. x86, x64, game consoles, mobile) are you looking to target?
  Basic mainstream platform: Win10, Win7, iOS, Android, PS, XBox, Linux, MacOS, also support x86, x64, arm, arm64 etc..

• Which characteristic or feature of another language/platform would you like to see in a Native AOT solution for .NET.

1. I also wants LLVM IR here with keep LLVM IR consistently in the different platform.
2. need hybrid aot mode(interpreter + aot or jit + aot) to hotreload code

[jtbrower]

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]

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]

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

[sgf]

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

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]

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]

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

[pjmlp]

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]

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]

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

[Perksey]

It is, it’s called CrossGen

…

On Wed, 7 Oct 2020 at 11:22, pjmlp ***@***.***> 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 <#41522 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVEYI23MO6WBVGXZGGRJU3SJQ6NBANCNFSM4QOIOKZQ> .

[DQRC69420]

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]

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