Runtime: Epic: Support Apple Silicon

Created on 12 Oct 2020  ·  39Comments  ·  Source: dotnet/runtime

Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon”. This epic tracks the high level status of the milestones required to ship this feature in .NET 6.

.NET 6 will include new runtime id -- osx-arm64 -- for targeting this hardware. It refers to the macOS operating system running on Apple Silicon devices.

.NET 5 - CoreCLR

  • [ ] Support .NET Core 5 with Rosetta 2 emulation #44897

.NET 6 - CoreCLR

Functionality

  • [x] Support compilation targeting osx-arm64
  • [x] Modify code generation to support osx-arm64 security features
  • [ ] Modify code generation to support osx-arm64 interop with native libraries

Testing

  • [x] Apple Silicon Prototype hardware available
  • [x] Manual testing of basic inner and outer loop tests
  • [x] Apple commercially shipping arm64 macos devices
  • [ ] CI/CD Testing enabled
  • [ ] CI/CD Stress testing enabled

Stability

  • [x] Basic tests passing rate > 99%
  • [ ] Stress tests passing rate > 99%
  • [ ] All tests passing rate > 99.9%

Availability

  • [x] .NET Core runtime nightly builds available
  • [x] ASP.NET Core runtime nightly builds available dotnet/aspnetcore#26821 (unstable)
  • [x] .NET Core SDK nightly builds available dotnet/installer#8840 (unstable)
  • [ ] .NET 6 preview available
  • [ ] .NET 6 release available

Details

See Enable .NET Core on Apple Silicon for the full set of related PRs and issues.

.NET 6 - Mono

Functionality

  • [x] Support compilation targeting osx-arm64
  • [x] Modify code generation to support osx-arm64 security features
  • [x] Modify code generation to support osx-arm64 interop with native libraries

Testing

  • [x] Apple Silicon Prototype hardware available
  • [ ] Manual testing of basic inner and outer loop tests
  • [ ] Apple commercially shipping arm64 macos devices
  • [ ] CI/CD Testing enabled
  • [ ] CI/CD Stress testing enabled

Stability

  • [ ] Basic tests passing rate > 99%
  • [ ] Stress tests passing rate > 99%
  • [ ] All tests passing rate > 99.9%

Availability

  • [ ] Runtime nightly builds available
  • [ ] .NET 6 preview available
  • [ ] .NET 6 release available

/cc @richlander @mangod9 @janvorli @JulieLeeMSFT @sandreenko @tommcdon @steveisok @directhex @akoeplinger @jeffschwMSFT

Team Epic arch-arm64 area-Meta os-mac-os-x-big-sur tracking

Most helpful comment

By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.

All 39 comments

By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.

Yup. Please file an issue @warrenrumak.

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

Indeed. Apple has confirmed to me that the Apple silicon Mac ABI is precisely the same as their iOS ARM ABI.

Yes, we don't support the arm64e stuff, but otherwise mono works on osx/arm64, both in the old mono repo and in dotnet/runtime. Couldn't run test suites because the sdk tools were hanging.

@jeffschwMSFT I'm not sure if this is supposed to be a team epic. This was created with @richlander. I thought it was supposed to be a customer facing epic.

This feels like the right level of scope to me. Thank you for helping to keep our progress tracked and visible.

Given how quick things are coming for true arm64 for apple in 6.0 perhaps it makes sense to make the changes for 5.0 rather than trying to make it work on rosetta 2?

The belief is that people will want a supported .NET product on Apple Silicon before November 2021. That's why we are enabling 5.0 in R2 as well as enabling 6.0 to run natively. Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.

@richlander would be good to have it at least running via Rosetta 2 asap.

@JaggerJo that work is tracked via #44897.

@richlander while I agree it should likely support both... is there a chance of bringing the native support to 5.0 so that a wait for nov 2021 is not needed?

We're going to finish adding functional-level Apple Silicon support to 6.0. At that point, we'll see the full set of changes that were required. We already think that the set of changes are too large to backport to 5.0, but we'll reserve judgment until later, and we'll also have a better sense of the market reaction/adoption to/of these devices (particularly around developers). In short, 5.0 native support is unlikely.

How do you plan to measure adoption of those devices? Telemetry will be out of the question, I assume.

Just to add a data point: I am a long-time .NET developer who switched to macOS many years ago. I've ordered two of those M1 machines to check if they might speed up my Xamarin and F# compilations, assuming that it will at least work with Rosetta. Would be nice if I had not to wait for months to be able to actually do that.

My network is not big but perhaps with the right sharing we will have an idea on the adoption...

https://twitter.com/galvesribeiro/status/1329895215549779973?s=21

Would be nice if I had not to wait for months to be able to actually do that.

Understood. .NET 5 Rosetta 2 emulation will be the quickest to release.

We already think that the set of changes are too large to backport to 5.0, but we'll reserve judgment until later

The initial native Apple Silicon change #40435 was huge. This is something that would be difficult to accept into the main .NET 5.0 servicing branch. It would involve too much risk to other platforms.

I've ordered two of those M1 machines

Yes we have some on order too. These will help light up CI and are a prerequisite to shipping native or even officially supporting Rosetta 2 emulation.

I haven't seen anyone bring up this so let me ask about this. Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code or this is just runtime support?

@Meowzz95 from what I've tried the SDK seems to work fine. Things fall apart when you try to run an app.

@JaggerJo Are you able to debug the code? I can't even start the debugger(using Rider under Rosetta 2)...

Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code

We want a full .NET 5 SDK running under Rosetta 2 with MS debugger support. (I can't speak for Rider)

The current .NET 5 version sometimes works. We used it initially to build dotnet/runtime for Apple Silicon. It would hang most of the time during the build, but occasionally it would succeed. We think we understand the root cause of the hangs.

I haven't tried running a debugger yet with .NET 5 + R2. Kind of strange given I work on the debugger.

Most of our debugging works fine on R2 and .net core. The one place debugging does not work is Azure Functions. Debugger hangs on startup, but running without debugger is fine. See here: https://github.com/Azure/azure-functions-core-tools/issues/2303

Well...

Screenshot 2020-11-23 at 22 12 24

When will the first stable release come? I just got the Macbook Air with the M1 chip and it's impossible for me to run Blazor applications :(
Good job though.

We are continuing to make incremental progress, once we get CI enabled with new hardware we should have a better handle on work required to get to parity with x64. Thx!

Sounds good, best of luck with it, I'll be waiting :)

So will I.

I decided to step by step move to the M1 MacBook Pro as it is such a great computer. It really is a step change from my point of view. Hopefully also with .NET 6 compilation times, and F# in particular 😄. Until we arrive there I will be happy to get good enough performance with Rosetta and .NET 5.

Is there a reason why .NET will only support Apple Silicon in a year when all other programming languages will be there in Q1 of 2021? What blocks Microsoft engineers from dropping support in a couple months like quite literally everyone else?

@dustinmoris our current approach is to first get support for Apple Silicon functional and performant. Once we have that we can consider where to enable support. At this point our current target is .NET 6, which will start having public previews early next year.

Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code

We want a full .NET 5 SDK running under Rosetta 2 with MS debugger support. (I can't speak for Rider)

The current .NET 5 version sometimes works. We used it initially to build dotnet/runtime for Apple Silicon. It would hang most of the time during the build, but occasionally it would succeed. We think we understand the root cause of the hangs.

I haven't tried running a debugger yet with .NET 5 + R2. Kind of strange given I work on the debugger.

I know you mentioned you wanted to get the 5.0 SDK running under Rosetta 2, would 3.1 also get the debugger issue fixed as well? Or would I need to upgrade my projects to 5.0 in order to use the debugger when that is addressed?

... Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.

@richlander Could you please elaborate why 6.0 would need R2 sometimes?

Could you please elaborate why 6.0 would need R2 sometimes?

@xhafan I'm not @richlander, but one such situation would be if your app has native x86 components that can't/won't be ported to ARM.

The other reason is that someone builds an app only for macOS x64 and people want it to run in on M1. Clearly, that's not preferred, but it is a scenario that should work.

The other reason is that someone builds an app only for macOS x64 and people want it to run in on M1. Clearly, that's not preferred, but it is a scenario that should work.

Really? Not sure if this is really a use case which needs support. Sounds like a hack. If an app is purposefully only build against macOS x64 then perhaps it should remain that way. If people want to run that app on M1 then they can pull the source and compile it themselves. If that is not possible then they should reach out to the developer of that app. Why overcomplicate things?

Really? Not sure if this is really a use case which needs support. Sounds like a hack. If an app is purposefully only build against macOS x64 then perhaps it should remain that way. If people want to run that app on M1 then they can pull the source and compile it themselves. If that is not possible then they should reach out to the developer of that app. Why overcomplicate things?

Its no more a hack than Rosetta2 is a hack. Wouldn't need emulation at all if recompiling everything was as simple as you say. Fact is, x86 code is expected to work on MacOS for the foreseeable future, and I don't hear a compelling reason to treat .NET apps differently.

I would say that, if .Net can run under Rosetta2 at least at the same acceptable performance at development time as it is on Intel Macs (some apps have been running 20-30% faster!), then it would be just fine to keep waiting for .Net 6 and use Rosetta2 for now.

I think the majority of people now that will use .Net on those M1s are developers and not final users so if they can at least use Rosetta2 to properly run VSCode/VSforMac and .Net extensions, they would survive.

Not running at all like in @aspnetde picture is what concern most of people...

Perhaps the adoption of .Net 6 previews will be way bigger than .Net 5 on Mac world if Rosetta2 will not become a viable option. 😄

Not running at all like in @aspnetde picture is what concern most of people...

To be fair, compiling worked and was as fast as on my then maxed-out 2016 MBP 15“. Only „the debugger“ crashed.

The belief is that people will want a supported .NET product on Apple Silicon before November 2021.

That really is a disappointment for me :(. Meanwhile the java people are churning out ready-to-use OpenJDK M1 builds which just work (for versions down to 8).

Keep up the good work and perhaps there will be a M1 build in less than 1 year :). I just hope so.

Regards,
Andreas

.Net dying on my M1 left and right.
I did have my Angular/Core project up and running with a custom configuration (didnt actually change any config), but after a VS update, the Core project will not run at all...at least I can play with angular and VS Code...but a little underwhelming without my API running

.Net dying on my M1 left and right.
I did have my Angular/Core project up and running with a custom configuration (didnt actually change any config), but after a VS update, the Core project will not run at all...at least I can play with angular and VS Code...but a little underwhelming without my API running

Very sorry to hear! We are tracking known Rosetta 2 issues on #44897.

Was this page helpful?
0 / 5 - 0 ratings