Rosetta is a translation process that allows users to run apps that contain
x86_64instructions on Apple silicon. Rosetta is meant to ease the transition to Apple silicon, giving you time to create a universal binary for your app. It is not a substitute for creating a native version of your app.To the user, Rosetta is mostly transparent. If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times.
A short overview of Rosetta 2, the translation layer that allows 64bit x86 applications to run on the upcoming ARM-based Macs.
Well, they omitted the one thing that most of us are most interested in hearing about, which is how well it actually performs.
I’m kind of surprised that they don’t support any AVX extensions. I would expect that to be fairly low hanging fruit unless they just figured it wasn’t worth supporting more demanding x86 software.
I’m most intrigued to find out if the “virtualisation” feature will emulate X86-64, or if it’s strictly ARM only. There was no mention of Windows support in the keynote, but that doesn’t mean it’s not possible. The “Linux and other platforms” comment seems to allure to Windows support, but maybe that’s just Windows on ARM, leaving Microsoft to come up with their own ARM to x86-64 compatibility layer in Windows if they wish to support new Macs.
ARM Macs are probably the biggest thing to happen to consumer ARM hardware since the Acorn RiscPC in the 90’s, or more recently, the hobbyist Raspberry Pi and similar SBCs. ARM Macs may finally hail the introduction of open, general purpose, ARM desktops and laptops, especially if other manufacturers follow suit.
Linux has/will have ARM distributions that can be run without emulation.
Maybe Windows 10 ARM will run on the new Macs. I don’t see Apple providing full x86 emulation for a “boot camp” experience – but the virtualisation software may well include x86 emulation capabilities for running an x86 Windows inside a virtual environment.
It will be interesting to see how well the new Macs – and optimised software – work in their own right. If they work well, it might spur more development of/for Windows 10 on ARM. It might lead to a true heterogeneous Windows environment – where power users are still using x86 chips pushing the limits of what a desktop can do, whilst laptops and high density servers move more towards ARM.
The123king,
I’m probably reading your question wrong, but rosetta 2 emulates x86-64 mac applications. I haven’t heard anything about whole system emulation. IMHO it wouldn’t be worth buying an ARM PC only to run an emulated x86 OS on it. The performance penalty is likely going to be fairly severe. There’s no hardware acceleration like in parallels.
I’d be interesting in whether owners will be allowed to dual boot alternative ARM operating systems (windows or linux). Apple may choose to block alternatives on ARM just like microsoft does.
Alfman, the feature The123king is referring to was announced as part of the keynote. They called it “virtualization” (no great branding there) and demoed a Linux VM running a webserver, which they accessed from a native client. What The123King is getting at is what they didn’t say: they didn’t say Windows and they didn’t say it was an x86 Linux VM. The press release (https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/) says Linux VMs, no mention of Windows, so it’s possibly a virtual ARM machine. Also the demo didn’t really try to interact with the VM itself, so presumably video performance is awful.
malxau,
I see, thanks for the clarification!
Just quoting the relevant portion…
Just guessing, but I would suspect it’s an ARM version of linux running natively in a VM using AArch64 virtualization. I would imagine the announcement would have included windows if it worked. But that is a good question, The123king!
Assuming the linux VM runs well enough, you could technically emulate windows on the linux side even if macos doesn’t support it. Not something I’d care to do other than to show that it works, haha,
>> they didn’t say it was an x86 Linux VM
https://twitter.com/wongmjane/status/1275180465553465344
Linux 4.19.0-9-arm64 on aarch64
No Roseta translation (not emulation) for OS virtualization.
When we talk about performance, there are a couple of aspects that are important – first, how responsive an application is, and secondly, how much energy is consumed.
The more demanding the x86 application, the harder it is to meet expectations on both of those fronts.
Emulation is a catch-all for software that hasn’t been updated. It might be a stop gap for people who need to purchase new hardware and can’t afford to update their software immediately.
But if you are using demanding x86 software on a new ARM machine, then you are likely to be suffering at least one of poor responsiveness and high(er) battery drain.
I wonder if Rosetta cannot handle AVX because Apple Silicon SIMD is limited to 128 bit, conforming to ARMv8 and not to the upcoming ARMv9.
If so, some workloads won’t be as fast as they were on x86.
Armv8.2-A already provides a vector unit up to 2048 bits length: https://arxiv.org/pdf/1803.06185.pdf
Actual length limit is clearly a design choice. Fujitsu A64FX implements 512 bit length SVE while meeting the Armv8.2-A specifications.
XtoF,
Well, native software should perform fine in terms of desktop experience. A lot of people have been optimistic about MT performance, but so far that remains to be seen.
In terms of rosetta x86 emulation performance, it would have been nice of apple to share some benchmarks, but my prediction is that it won’t be good. It never is. I think even 50% of native could be too optimistic. We’ll see though, hopefully somebody makes the benchmarks available.
It’s not as much as the width of the SIMD unit, but as the functionality the SIMD unit in ARM’s neon etc is very different, mainly not as complete, from what AVX supports.
The width of SIMD is irrelevant.
That matter is:
– Intel patents. The risk of lawsuit is very high.
– Code complexity and coverage – AVX emulation requires a lots of code for little value.
More code -> more bugs and incompatibilities.
– SSE2 is baseline. AVX-only programs without SSE2 fallback are rare.
– 256-bit AVX instructions emulated on 128-bit would be slower than SSE2 fallback.
I think many are confusing emulation and translation for being the same idea. It’s not. Nor is it virtualisation.
I’ve had extensive arguments with set-in-stone people about Parallels on MacOS.
Parallels uses virtualisation for hardware to emulate an is that uses translate system calls.
Apple and parallels have a long standing love/hate relationship with deep partnering.
From the documentation I’ve read Rosetta 2 is more of a JIT porting from AMD64 to ARM.
Given the demo of RotT it looks to be well done. Obviously none of us will know till actual ARM systems end up in developer’s hands.
lostinlodos,
For better or worse emulation has become an umbrella term. The name “emulator” sticks even as the implementations evolve. Look at qemu, strictly speaking QEMU translates the code and can use virtualization as well, but it’s authors use the term “emulation” thoroughly to describe itself:
https://www.qemu.org/docs/master/
Personally I would use the term “simulator” to describe BOCHS since it goes beyond emulation, it simulates the internal state of the computer. I would use the term “emulator” for QEMU since it emulates a computer even though it doesn’t simulate one per say. QEMU uses code translation and virtualization, but those are just implementation details and IMHO it’s still accurate to call it an emulator.
I don’t really care what people call it, but here’s a discussion on stack overflow for the pedantic readers among us, haha.
https://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference
Good call. I’m just pointing out that Rosetta 2 is VERY different from the original.
Rosetta 2 pre-translates the binary during install unlike the original Rosetta which was JIT. I think JIT is still available for certain scenarios.
modmans2ndcoming,
That’s my literal interpretation as well, with apple suggesting it’s compiled beforehand. However I’m not so sure apple’s statement was written by an engineer (for engineers like us). Here are apple’s own words:
This might well be the way someone would explain JIT compilation to a layman without going into much detail (like ongoing compilation phases as needed). So it’s kind of hard to tell if this is apple’s way of describing JIT compilation, or if they are in fact pre-compiling the binaries.
Also this statement from apple implies that rosetta 2 does at least implement JIT compilation even if it isn’t the default.
I wouldn’t be surprised if they are just using JIT and caching the results to improve performance in the future. I think it makes sense to wait for more details before jumping to any conclusions. It will be interesting to see if their emulation works better than QEMU’s and microsoft’s.