The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test
by Andrei Frumusanu on November 17, 2020 9:00 AM ESTRosetta2: x86-64 Translation Performance
The new Apple Silicon Macs being based on a new ISA means that the hardware isn’t capable of running existing x86-based software that has been developed over the past 15 years. At least, not without help.
Apple’s new Rosetta2 is a new ahead-of-time binary translation system which is able to translate old x86-64 software to AArch64, and then run that code on the new Apple Silicon CPUs.
So, what do you have to do to run Rosetta2 and x86 apps? The answer is pretty much nothing. As long as a given application has a x86-64 code-path with at most SSE4.2 instructions, Rosetta2 and the new macOS Big Sur will take care of everything in the background, without you noticing any difference to a native application beyond its performance.
Actually, Apple’s transparent handling of things are maybe a little too transparent, as currently there’s no way to even tell if an application on the App Store actually supports the new Apple Silicon or not. Hopefully this is something that we’ll see improved in future updates, serving also as an incentive for developers to port their applications to native code. Of course, it’s now possible for developers to target both x86-64 and AArch64 applications via “universal binaries”, essentially just glued together variants of the respective architecture binaries.
We didn’t have time to investigate what software runs well and what doesn’t, I’m sure other publications out there will do a much better job and variety of workloads out there, but I did want to post some more concrete numbers as to how the performance scales across different time of workloads by running SPEC both in native, and in x86-64 binary form through Rosetta2:
In SPECint2006, there’s a wide range of performance scaling depending on the workloads, some doing quite well, while other not so much.
The workloads that do best with Rosetta2 primarily look to be those which have a more important memory footprint and interact more with memory, scaling perf even above 90% compared to the native AArch64 binaries.
The workloads that do the worst are execution and compute heavy workloads, with the absolute worst scaling in the L1 resident 456.hmmer test, followed by 464.h264ref.
In the fp2006 workloads, things are doing relatively well except for 470.lbm which has a tight instruction loop.
In the int2017 tests, what stands out is the horrible performance of 502.gcc_r which only showcases 49.87% performance of the native workload – probably due to high code complexity and just overall uncommon code patterns.
Finally, in fp2017, it looks like we’re again averaging in the 70-80% performance scale, depending on the workload’s code.
Generally, all of these results should be considered outstanding just given the feat that Apple is achieving here in terms of code translation technology. This is not a lacklustre emulator, but a full-fledged compatibility layer that when combined with the outstanding performance of the Apple M1, allows for very real and usable performance of the existing software application repertoire in Apple’s existing macOS ecosystem.
Facebook
Twitter
RSS
682 Comments
View All Comments
GeoffreyA - Thursday, December 3, 2020 - link
Sad, but true. I remember his "Road Ahead" article in 2014 and that was it. Gone. Well, let's hope the man leaves Apple someday and comes back home to Anandtech. I know, the chances of that happening are exceedingly slim.pjc15 - Saturday, November 21, 2020 - link
This might be evidence that ARM is the way of the future, but Intel, AMD, and Microsoft are too entrenched in x86 to do anything about it. They would have to maintain x86 and ARM versions of everything, and on the hardware side especially, they don't seem to have the bandwidth to do that. Maybe custom servers will move to ARM, maybe some types of pros will move to macOS if Apple's lead extends, but for the vast majority of cases, x86 is good enough and cheap enough that Wintel will be unaffected. In order to upend the industry, Apple would have to sell its chips to OEMs, or sell sub-$500 computers, both of which have almost no chance of happening.profquatermass - Sunday, November 22, 2020 - link
So where does the M1 go from here?How can they make the M2?
Spunjji - Monday, November 23, 2020 - link
The next move will probably be a larger variant with more (8?) large cores, more (+50%?) GPU resources, a wider (256bit?) memory bus, and LPDDR5. They're all fairly obvious ways to provide higher performance, but they mean a larger die, which means lower yields on a 5nm process that's still in its early stages.utferris - Wednesday, November 25, 2020 - link
I hope there will be Apple ISA. ARM ISA can be limiting at some point if apple want to have their own custom instructions for better performance.And NVidia will be owning ARM, which is the worst thing to Apple and the world.
Focher - Thursday, November 26, 2020 - link
Nvidia owning ARM will have zero impact on Apple.tokale - Friday, November 27, 2020 - link
This is the biggest misconception out there, some folks think Apple's chip fate it tied to ARM. Truth is the only thing ARM related to Apple's chips is the instruction set, everything else's is Apple's.PickUrPoison - Saturday, December 12, 2020 - link
True. But OP is right about instruction set extensions. Do we know there aren’t any? I expected some for perhaps the purpose of Rosetta2 performance acceleration, esp for the on the fly emulation vs. Rosetta2 translation.helpmeoutnow - Thursday, November 26, 2020 - link
looks like another bubble from Apple. but they will sell it as something amazing.PickUrPoison - Saturday, December 12, 2020 - link
Yes, congratulations to Apple, absolutely! As Andrei said, “overall, Apple hit it out of the park with the M1”.