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
realbabilu - Thursday, November 19, 2020 - link
Since Catalina,intel compiler mafia have issue and incompatibility. The big sur have worse compatibility.https://community.intel.com/t5/Intel-C-Compiler/In...
That's why my hackintosh stay at mojave. The only works for now is gcc apple, and it doesn't have gfortran. I don't know if latest gnu gcc Catalina could works in big sur rosetta 2.
realbabilu - Thursday, November 19, 2020 - link
Dull t9Should be intel compiler have issue
Phemg - Thursday, November 19, 2020 - link
It would be nice a comparison of multi-thread against efficiency cores...QuantumKot - Thursday, November 19, 2020 - link
I wonder whether Apple has removed support for 32 bit instructions from the M1 hardware altogether or it is still there just in case?Jenoin - Thursday, November 19, 2020 - link
"it takes a Ryzen laptop with a Radeon 560X to finally pull even with the Mac Mini"Oh really? A Ryzen, that was the slower of two products in it's product stack, when it launched 3(!) years ago on a 14nm process coupled with a 2 year old refreshed version of a refreshed version of a refreshed version... 14nm GCN based GPU. What do you think the market value of such a laptop would be today assuming you could find one new? $250? $300? This comparison and the language used for it is disingenuous at best.
What a joke.
hagjohn - Thursday, November 19, 2020 - link
Apple Silicon allows Apple to be in the drivers seat. There is no more waiting for intel to release products, which has been pretty hard lately. They have done a damn good job with their first product. I'm excited to say I ordered a M1 Mini (16GB/1TB) and I can't wait to get it.Alexvrb - Friday, November 20, 2020 - link
I'd like to see Rosetta2 compared to the Windows ARM's x86 support. Obviously the QC chip isn't as fast, but I mean as a % of native performance. I'm sure Apple's version has less overhead, but I'm still curious how big the gap is.alufan - Friday, November 20, 2020 - link
Hmm no Nvidia GPU reviews and now no AMD GPU reviews?Seems Anandtech is becoming an intel and Mac site either that or you have seriously annoyed some folks who send out review kits
tuxRoller - Saturday, November 21, 2020 - link
This is a FAR more interesting story. We've finally got a major desktop player going all in with arm and the results are astonishing.That kind of change doesn't happen often.
If you want to read about how many more fps you can get with the news cards read any of more than a dozen benchmarking sites.
Spunjji - Monday, November 23, 2020 - link
I was hoping for an architectural deep-dive on both of them that you don't usually get from other sites.I'm still hoping for that, tbh. I don't much care about it being "on time". It's still beginning to get worrying how badly things have gone, though.