Rosetta 2

[Birkan]

I guess it makes sense that Apple is going the Rosetta route again, this time with version 2.

I hope it’s less buggy than applications were under the original Rosetta, but I’m not optimistic. Nonetheless, I’m still thinking this transition will be smoother than the first one.

I’m also guessing performance will be about 40-50% native, which much higher RAM usage.

I’m curious, what does “applications translated at install” mean?

Can we assume Boot Camp is toast?

I watched Port your Mac app to Apple Silicon session from WWDC last night. They only gave a specific example (which starts around 24:10) of executing a unit test natively in 21 ms on Arm64 to 29 ms on Rosetta 2 running on Arm64. For this specific use case (which is definitely not a general comparison at all) it seems like around 38% slowdown or running around 72% of the native code. And this doesn't even account the potential performance loss due to use of SSE or AVX instructions which are not supported on translation. So developers will have to provide appropriate SIMD instructions or better use Accelerate or Compressor frameworks which have performant implementations of such instructions for Arm64. Furthermore, we do not know if Apple will include any SVE or SVE2 instructions on consumer Macs that they will release later this year. SVE2 would be super nice if they can implement it in time since it can offer significant improvements compared to NEON.

I expect that most of the casual apps such as Chrome, Edge, Spotify, Discord, Slack, VS Code and tools such as git, homebrew, docker, clang, llvm, gcc, nodejs, python3 will be compiled and available (if not already) for Arm64 by the time we actually get any consumer Mac hardware.

The main problem will be old binaries that are no longer maintained so we will either have to run the whole app with Rosetta 2 or just move on to alternative Arm64 frameworks since Apple does not allow you to mix and match x86_x64 and Arm64 code in a single app. However, I expect that we'll see some Rosetta 2 related performance scenarios in around 2 weeks (I saw some shipments dates around 9th of July on Twitter) when developers get the DTK hardware.

 

[EugW]

I watched Port your Mac app to Apple Silicon session from WWDC last night. They only gave a specific example (which starts around 24:10) of executing a unit test natively in 21 ms on Arm64 to 29 ms on Rosetta 2 running on Arm64. For this specific use case (which is definitely not a general comparison at all) it seems like around 38% slowdown or running around 72% of the native code. And this doesn't even account the potential performance loss due to use of SSE or AVX instructions which are not supported on translation. So developers will have to provide appropriate SIMD instructions or better use Accelerate or Compressor frameworks which have performant implementations of such instructions for Arm64. Furthermore, we do not know if Apple will include any SVE or SVE2 instructions on consumer Macs that they will release later this year. SVE2 would be super nice if they can implement it in time since it can offer significant improvements compared to NEON.

I expect that most of the casual apps such as Chrome, Edge, Spotify, Discord, Slack, VS Code and tools such as git, homebrew, docker, clang, llvm, gcc, nodejs, python3 will be compiled and available (if not already) for Arm64 by the time we actually get any consumer Mac hardware.

The main problem will be old binaries that are no longer maintained so we will either have to run the whole app with Rosetta 2 or just move on to alternative Arm64 frameworks since Apple does not allow you to mix and match x86_x64 and Arm64 code in a single app. However, I expect that we'll see some Rosetta 2 related performance scenarios in around 2 weeks (I saw some shipments dates around 9th of July on Twitter) when developers get the DTK hardware.

Users of the dev kit are not allowed to post benchmarks AFAIK.

 

[Birkan]

Users of the dev kit are not allowed to post benchmarks AFAIK.

You are correct that they won't be able to post benchmarks directly. However, I still expect more conversation about general performance of apps being ported to the new architecture. They might be able to talk about ballpark estimations. Also, there will be inevitable leaks unless Apple does very intrusive logging about what's going on on those machines which I do not expect at all. Let's wait and see

 

[maflynn]

guess it makes sense that Apple is going the Rosetta route again, this time with version 2.

No matter the name, any platform change was going to require an emulation for existing/legacy apps. If it didn't people wouldn't really be quick to embrace the new platform

 

[EugW]

No matter the name, any platform change was going to require an emulation for existing/legacy apps. If it didn't people wouldn't really be quick to embrace the new platform

I agree, but before the announcement, some people believed Apple could get away without it this time around.

 

[leman]

I watched Port your Mac app to Apple Silicon session from WWDC last night. They only gave a specific example (which starts around 24:10) of executing a unit test natively in 21 ms on Arm64 to 29 ms on Rosetta 2 running on Arm64. For this specific use case (which is definitely not a general comparison at all) it seems like around 38% slowdown or running around 72% of the native code. And this doesn't even account the potential performance loss due to use of SSE or AVX instructions which are not supported on translation.

At the same time, executing all tests (30 seconds before) showed virtually no difference between native or Rosetta. So no idea what the actual ratio is.

BTW, SSE is supported by Rosetta.

 

[Birkan]

At the same time, executing all tests (30 seconds before) showed virtually no difference between native or Rosetta. So no idea what the actual ratio is.

BTW, SSE is supported by Rosetta.

Hey, you’re right. I seem to have missed those numbers there. So 36 unit tests took 1.148 seconds on Arm64 and 1.157 seconds on x86_64. Idk if xcodebuild uses some sort of caching to prevent identical rebuilds but if it’s not then the comparison seems to be pretty good. Then my original comparison just shows how wide the gap can be.

So if SSE is supported, then I guess they are translating them directly to NEON since both of them are 128-bit wide which is pretty cool. I used SSE before but don’t know if SSE and NEON exactly have same operations (alignment, load/store, math stuff etc.).

 

[leman]

So if SSE is supported, then I guess they are translating them directly to NEON since both of them are 128-bit wide which is pretty cool. I used SSE before but don’t know if SSE and NEON exactly have same operations (alignment, load/store, math stuff etc.).

My guess is that they are raising x86 bytecode to LLVM IR and then optimizing+compiling to ARM. So it should use Neon where appropriate. I didn’t work much with it, but AMD64 SIMD is really nice. One thing it lacks is the mask extraction tools of SSE... but it can also supports fast horizontal operations (something Intel doesn’t have).

 

[MrGunnyPT]

I'm sold on Apple Silicon idea (not the hardware itself because we haven't seen it)

However I'm still worried about the Windows VM, I'm not sure if I can survive using just my MacOS without a Windows VM. Might have to do a Windows VM via Docker or something to get the ball rolling.

I'll play the wait and see game especially when it comes down to the Virtual Machines running Windows on these new MacOS machines.

 

[Petri Krohn]

I have not had time to read anything on Rosetta 2, but this is my speculation based on some cross-compiler / linker / loader software I wrote 30 years ago:

Rosetta 2 is not an emulator. It is a compiler that translates from one instruction set to another. This translation is part of the process where code and libraries are loaded into caches. Most likely Rosetta 2 is integrated into the dynamic linker dyld.

The compiled code should execute at nearly native speed. Microsoft has a similar system for its Windows 10 ARM version. It works both ways; ARM apps can be executed on Intel PCs.

The translation maps instructions and registers from one instruction set architecture to another. It is easy to compile from a limited instruction set to a more advanced instruction set. The Windows 10 implementation is good at translation 32-bit x86 and ARM core to 64-bit processors. It may not be able to translate 64-bit code.

Apple has depreciated 32-bit apps, so I believe Rosetta 2 should be able to handle 64-bit code. One way of making this possible might be to limit compiler output to a common subset of instructions and registers. (This may be one reason why Big Sur does not use AVX instructions.)

I believe the most difficult part in instruction set translation would be compiling from Big-Endian to Little-Endian code and vice versa. The compiler would need to know the semantics of the data. Luckily both Intel x86 and ARM are Little-Endian. PowerPC is is Big-Endian, which might have made translating from PPC to Intel difficult.

***
From the Microsoft site:

How x86 and ARM32 emulation work on ARM - UWP applications

Learn how emulation for x86 apps makes the rich ecosystem of existing Win32 apps available on ARM devices.

docs.microsoft.com

"x86 emulation works by compiling blocks of x86 instructions into ARM64 instructions with optimizations to improve performance. A service caches these translated blocks of code to reduce the overhead of instruction translation and allow for optimization when the code runs again. The caches are produced for each module so that other apps can make use of them on first launch."

 

[MichaelLAX]

Rosetta 1 lasted 4 years, IIRC. Snow Leopard in 2009 killed it.

Actually Lion in 2011 killed it; and Snow Leopard is the last version of OS X 10.6.8 that still runs Rosetta. Many people still run Snow Leopard, or Snow Leopard Server in Parallels to access their PowerPC apps

 

[Tagbert]

Did Rosetta 1 eventually get pulled? Now that MS Office has gone the subscription route I'm assuming Rosetta 2 will be our only way to keep running Office '19.

Did you see the keynote presensation where they showed various Office apps already recompiled for Apple Silicon? You won’t need Rosetta 2 for Office.

 

[EugW]

Did you see the keynote presensation where they showed various Office apps already recompiled for Apple Silicon? You won’t need Rosetta 2 for Office.

Well it depends on what they release. I own Office 2016 but would hate to be forced into a subscription model on Arm. Plus, I suspect the Arm version may be buggy until after the first few updates.

 

[Woochoo]

they believe they will continue to sell Intel Macs for years to come. They are in prime marketing hype mode right now, as they should be, but when the first ARM macs start to roll-out, we will see reports of these limitations and downsides. A great future is ahead, but there will be some rocky moments during this transition period.

They said the transition would be over 2 years, so I expect them to still sell some Intel machines (specially the high end ones as they start going ARM from the low end and scaling). But Intel Macs will be an afterthought pretty soon, there's no way Apple holds the ARM-Intel situation for a long as it's more headaches than benefits, they just want the transition to be fast.

I was finally convinced when I saw the A12Z running the "translated" Maya 3D flawless. I mean Autodesk stuff is the typical one that many professionals use but they just don't give a **** about properly updating their products, let alone porting it into other architectures. Heck, they didn't even code Revit for macOS and it was basically the same architecture. So being able to run without any problems the "worst case scenario" was just banging fist on the table from Apple. That and playing Tomb Raider, a PC game ported into Mac (so not precisely optimized), translated into ARM running decently in a 7W tablet SoC. That was just enough for me

 

[WebHead]

Did you see the keynote presensation where they showed various Office apps already recompiled for Apple Silicon? You won’t need Rosetta 2 for Office.

Well it depends on what they release. I own Office 2016 but would hate to be forced into a subscription model on Arm. Plus, I suspect the Arm version may be buggy until after the first few updates.

Yes, as EugW notes it'd be better not to be forced into a subscription model if you don't want to be.

 

[dmccloud]

Well it depends on what they release. I own Office 2016 but would hate to be forced into a subscription model on Arm. Plus, I suspect the Arm version may be buggy until after the first few updates.

There is a reason Microsoft already had an ARM based version of Office ready to go for the WWDC keynote - the Surface Pro X is built on an ARM based processor, so they have literally already done the work to recompile the apps for ARM.

 

[EugW]

There is a reason Microsoft already had an ARM based version of Office ready to go for the WWDC keynote - the Surface Pro X is built on an ARM based processor, so they have literally already done the work to recompile the apps for ARM.

I'm not a programmer, but my understanding is the codebase for Windows Arm Office would be different than macOS Arm Office.

 

[leman]

There is a reason Microsoft already had an ARM based version of Office ready to go for the WWDC keynote - the Surface Pro X is built on an ARM based processor, so they have literally already done the work to recompile the apps for ARM.

I'm not a programmer, but my understanding is the codebase for Windows Arm Office would be different than macOS Arm Office.

EugW is correct. The codebase for macOS ARM Office would be the same as that of the macOS Intel Office (duh).

 

[dmccloud]

EugW is correct. The codebase for macOS ARM Office would be the same as that of the macOS Intel Office (duh).

EugW said the codebases were different, not the same. But that is incorrect. If I'm coding an app in Objective C, the code base is the same regardless of what OS I'm coding for. The difference is in some of the function calls and OS hooks that have to be used, but the vast majority of the code is unchanged between the versions. This principle is why newer versions of Microsoft Visual Studio support one stop coding for Windows, Android, and iOS - you write the code once, and VS compiles that into OS-specific binaries, substituting Windows function calls for Android/iOS function calls as required.

 

[EugW]

EugW said the codebases were different, not the same. But that is incorrect. If I'm coding an app in Objective C, the code base is the same regardless of what OS I'm coding for. The difference is in some of the function calls and OS hooks that have to be used, but the vast majority of the code is unchanged between the versions. This principle is why newer versions of Microsoft Visual Studio support one stop coding for Windows, Android, and iOS - you write the code once, and VS compiles that into OS-specific binaries, substituting Windows function calls for Android/iOS function calls as required.

What I had said was I had understood that Office Mac and Office Windows Arm had different code bases. @leman then said Office Mac Arm and Office Mac Intel would be the same. This doesn't disagree with what I said.

I made that statement because MS said that originally Office Mac was written from the ground up with a new code base. This is partially why for example some features were left out Office Mac, whereas some other features only existed in Office Mac and not the Windows version.

However, that was a while ago. So, I just looked this up again, and it turns out that as of 2018, Office Mac shares the code base with the Windows version.

https://twitter.com/i/web/status/954037656677072896

 

[Janichsan]

However, that was a while ago. So, I just looked this up again, and it turns out that as of 2018, Office Mac shares the code base with the Windows version.

And yet, there are still massive differences between the most recent Windows and Mac versions of Office 2019...

 

[Ritsuka]

The documented rendering part is shared. The UI is totally platform specific (aside some weird macro UI elements).

 

[dmccloud]

And yet, there are still massive differences between the most recent Windows and Mac versions of Office 2019...

I don't use Office 2019, but I have been using Office (now Microsoft) 365 for a few years now. The biggest difference between the Mac and Windows versions outside of some UI changes is the lack of Access and Publisher on the Mac side. But there is one thing I love specifically about Office 365. I can start a doc on either the Windows or Mac and save it to One Drive instead of saving it locally, then open it on the other machine as you can do with Handoff on Mac/iOS. I can also have the core Office apps (Word/Excel/Powerpoint/One Note) on my iOS or Android devices and access those files in the same fashion. From a user perspective, items in the toolbars are in the same locations on both OSes, so I don't have to know two different layouts at the same time.

That tweet EugW posted earlier is what I was referring to earlier though. Microsoft has already ported Office to ARM because of the Surface Pro X and Samsung's Galaxy Book S series (although it looks like Samsung will be switching to Intel going forward). That's why it was relatively trivial to get it up and running on an A13 based Mac for the WWDC keynote.

 

[leman]

That tweet EugW posted earlier is what I was referring to earlier though. Microsoft has already ported Office to ARM because of the Surface Pro X and Samsung's Galaxy Book S series (although it looks like Samsung will be switching to Intel going forward). That's why it was relatively trivial to get it up and running on an A13 based Mac for the WWDC keynote.

I think you might be mixing up things a bit. Windows on ARM is not the same as Mac on ARM and just because you have an app ready on Windows ARM does not mean that you can easily port it to an ARM Mac.

They just took the regular Office for Mac, compiled it with Xcode, ran the tests and fixed one or two latent bugs that got exposed by the difference between x86 and ARM. That’s it. Porting to Apple ARM is for most time trivial. It’s mostly about bug checking really. You only need extra effort if you heavily rely on CPU-specific intrinsics.

 

[dmccloud]

I think you might be mixing up things a bit. Windows on ARM is not the same as Mac on ARM and just because you have an app ready on Windows ARM does not mean that you can easily port it to an ARM Mac.

They just took the regular Office for Mac, compiled it with Xcode, ran the tests and fixed one or two latent bugs that got exposed by the difference between x86 and ARM. That’s it. Porting to Apple ARM is for most time trivial. It’s mostly about bug checking really. You only need extra effort if you heavily rely on CPU-specific intrinsics.

You're correct that Microsoft had to fix some Mac-OS specific bugs, but we know that Microsoft is using the same code base across all platforms now. Therefore, when Microsoft ported the Windows version to ARM, a lot of the ARM-specific bugs that resulted from the x86 to ARM transition were already worked out. Think of there being two classes of bugs related to moving from X86 to ARM - one is related to the OS in use, the other class is related to the architectural differences between x86 code and ARM code.