Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Developers can use native AOT experiment to target Windows and Linux ARM64 #336

Closed
19 of 21 tasks
agocke opened this issue Nov 10, 2020 · 16 comments
Closed
19 of 21 tasks
Labels
Priority:1 Work that is critical for the release, but we could probably ship without Team:Runtime User Story A single user-facing feature. Can be grouped under an epic.

Comments

@agocke
Copy link
Member

agocke commented Nov 10, 2020

Right now Native AOT runs on significantly fewer platforms than CoreCLR. We think that extending support to ARM64, which is already supported by CoreCLR, would be useful in identifying costs and benefits of the Native AOT form factor.

We'd like to add compatibility for Windows and Linux ARM64 to the Native AOT experiment and bring the experience closer to traditional CoreCLR form factors.

Work tracking

runtimelab Infrastructure

  • Official builds for runtime labs
  • Runtime labs all-up publishing

runtimelab Windows, Linux x64 bring-up

  • Move CoreRT tests to use CoreCLR testing infra
  • Fix test failures
  • Run CoreCLR tests
  • Fix top test failures

Archive CoreRT Repo

  • Mop-up integration CoreRT -> runtimelabs
  • Move documentation from dotnet/corert
  • Archive CoreRT

Improve reflection experience

  • IL linker annotation support

Debugging

  • Infrastructure for more SOS support
  • DumpLog, DumpHeap, VerifyHeap and DumpAsync commands

ARM64 Compatibility

  • Linux ARM64 build
  • Test infrastructure (packaing tests on build machine and execute them on Linux ARM64 box)
  • Linux ARM64 smoke tests
  • Fix top test failures
  • Windows ARM64 build
  • Windows ARM64 smoke tests
  • Windows ARM64 fix top test failures

Improved Linux tracing

  • Finish refectoring EventPipe to be shared between CoreCLR and Mono
  • Integrate new EventPipe implementation into Native AOT
@agocke
Copy link
Member Author

agocke commented Nov 10, 2020

cc @jkotas @MichalStrehovsky

@agocke agocke added Priority:0 Work that we can't release without Team Epic User Story A single user-facing feature. Can be grouped under an epic. and removed Team Epic labels Nov 16, 2020
@jeffschwMSFT
Copy link
Member

@agocke can you parent this under the right theme

@agocke
Copy link
Member Author

agocke commented Nov 20, 2020

@jeffschwMSFT Since this is a User Story, I added it to the #248 Epic. Does that look right to you?

@charlesroddie
Copy link

charlesroddie commented Nov 22, 2020

ARM64 support is great but there is a lack of a user story here to match the ambitions of the title ("widen platform compatibility").

Here are some major .Net platforms with the current state of support:

Platform AOT support in .Net Work for nAOT support Estimate
Windows GUI (UWP/WinForms/WPF/Avalonia) No (Avalonia only; UWP is regression) COM interop Medium
Xamarin Mac/iOS Partial via mono ARM64 + hooks Large
Xamarin Android Partial via mono ARM64 + hooks Large
Blazor client Planned for mono WASM + hooks ?
Traditional web (ASP.Net/Blazor server) No Reflection-free web frameworks Large?

@agocke
Copy link
Member Author

agocke commented Nov 23, 2020

We use the term "platform" to refer to OS+arch, these are what I would call "app frameworks"

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

@danmoseley
Copy link
Member

@agocke we are trying to fix all user story titles to be in terms of the user visible result. Is this a reasonable title: "Developers can use AOT to target Windows and Linux ARM64" ?

@jkotas
Copy link
Member

jkotas commented Nov 29, 2020

"Developers can use AOT to target Windows and Linux ARM64"

Developers can use native AOT experiment to target Windows and Linux ARM64

@danmoseley danmoseley changed the title Widen platform compatibility for the Native AOT experiment and provide updated packages Developers can use native AOT experiment to target Windows and Linux ARM64 Nov 29, 2020
@charlesroddie
Copy link

charlesroddie commented Dec 9, 2020

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps

It's valid to substitute "irrelevant" for "traditional command line-like" in the above sentence and it shows that he strategy is insane. There was a native aot framework (UWP), which was deployed in user-facing apps, has regressed with dotnet5, and you are saying that even after significant future development native AOT will still be unusable in practice.

@christianscheuer
Copy link

So happy with the direction this is all going in. Just a quick question from a customer who's been very happy with CoreRT on Intel Macs so far (and so are all of our customers in turn). Is there a particular reason why macOS was left out of this story?

@jkotas
Copy link
Member

jkotas commented Dec 10, 2020

The scope of this user story is tailored to the needs of customers we are working closely with on this project.

Once we have Windows and Linux ARM64 and macOS ARM64 works in mainline CoreCLR, I should be fairly trivial to enable macOS ARM64 as well. We will be happy to accept PR with the required changes and provide guidance along the way.

@christianscheuer
Copy link

Thank you, Jan! Really appreciate it.

@Symbai
Copy link

Symbai commented Jan 2, 2021

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

Does this mean the whole AOT thing here is just working for console applications and not for WPF application? If the answer is simply "yes" then I could save a lot of time wasting to read all guides, digging myself through the build process and fail on testing AOT on my WPF application.

Also if the answer is "yes" you might leave a note here: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/workflow/building/coreclr/nativeaot.md

@jamshedd jamshedd added Priority:1 Work that is critical for the release, but we could probably ship without and removed Priority:0 Work that we can't release without labels Jan 14, 2021
@vitordelucca
Copy link

We use the term "platform" to refer to OS+arch, these are what I would call "app frameworks"

At the moment we're not working on broadening app framework support, but focusing on traditional command line-like apps, while broadening support for more underlying platforms.

Is this still the idea? UWP is unusable without AOT. So this basically means developers who want performant UWP apps will need to use other frameworks than .NET?

@lukemcdo
Copy link

Would like to have it noted whether the resulting output binaries are also targeted for Alpine, or depend on glibc somehow. I assume that Alpine would be supported.

@jkotas
Copy link
Member

jkotas commented Mar 10, 2021

Would like to have it noted whether the resulting output binaries are also targeted for Alpine, or depend on glibc somehow. I assume that Alpine would be supported.

We just enabled Alpine builds. Please give it a try and file issues on any problems you run into.

The resulting binaries depend on either glibc or musl (same as regular .NET runtime), so you have to have a different native binary for Alpine ie dotnet publish -c Release -r linux-musl-x64.

@agocke
Copy link
Member Author

agocke commented Jul 19, 2021

This work appears to be largely complete, modulo any bugs we find

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:1 Work that is critical for the release, but we could probably ship without Team:Runtime User Story A single user-facing feature. Can be grouped under an epic.
Projects
None yet
Development

No branches or pull requests

10 participants