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
Rrrumble - Tuesday, January 25, 2022 - link
You may have missed the part where apple started the "business" (the smart phone, with the iPod as a first step) and grew and expanded it with savvy products and marketing while others tried catch up.Henry 3 Dogg - Friday, November 27, 2020 - link
"...Apple have tonnes of free cash that they could use to buy something they don't really need that makes money, but they don't do it. Instead they buy back their own stock. ..."Not true. Yes, Apple does buy back their own stock but they also have a subsidiary called Braeburn Capital which is sitting on around $250 Billion worth of investments.
theonetruestripes - Tuesday, December 1, 2020 - link
Apple _likes_ focus. When I worked there SJ made the point that Apple had incredible brand loyalty, but making some products that "make money" but are not as good as the rest of the products damages that brand loyalty. That seems pretty obvious to me at the time. Th other point he made is projects cost attention. If Apple launched a line of drink bottles it would take his time, designers time, marketing time, and many others. Some of that you can "just hire" if you have enough money, but you can't "just hire" more hours into the CEO's day, or SVP's days.To a certain extent that might not matter for something as distant from Apple's core business as say owning a CPU design firm. If Apple bought ARM and the ARM reference designs are "meh" very few people will decide that means the new MacBook Pro is "meh" by association. However it would still require some CEO time to decide "this new ARM subsidiary can't be called anything Apple related, and needs to make sure nobody is allowed to buy products from them and claim they are Apple related - we absolutely don't want a new "Apple Powered Dell" marketing campaign anywhere!"; how much money is that time worth? I'm sure there is some number at which you could say "if buying ARM makes this much per year it is worth 300 hours of Tim's time to close the deal and 16 hours per Q to make sure it doesn't screw anything up", but it may be a much higher number then ARM actually generates.
(or it might not, I expect a large part of Apple not being excited about buying ARM is lack of likelihood of getting regulatory approval, likelihood of needing to appear before congress to defend the purchase if in fact it is approved, and lack of any meaningful value to Apple (i.e. Apple has all the ARM license it needs to do anything it decides to))
alysdexia - Monday, December 28, 2020 - link
cares !-> they; 1 != 2; and you liardysonlu - Sunday, February 21, 2021 - link
If Apple buys Arm, not only does it have to keep licensing out Arm's designs but it may risk being forced to license its own CPU design/innovation as well since with Apple+Arm being a single entity, there is no longer any distinction in CPU intellectual properties between the two companies.Henry 3 Dogg - Friday, November 27, 2020 - link
Apple owned 43% of ARM for several years. There are more reasons than licensing technology to buy a all or part of a company.There are some very good reasons why Apple might choose to own 20% of ARM.
danbob999 - Tuesday, November 17, 2020 - link
Actually it's the opposite. It's the cheapeast/narrowest license from ARM. More expensive license include access to full Cortex cores, and not only instruction set.Spiderman10 - Tuesday, November 17, 2020 - link
No helios24 is correct. The Arch. license is at the top of the licensing pyramid. Anandtech actually wrote a piece about this here: https://www.anandtech.com/show/7112/the-arm-diarie...ws3 - Tuesday, November 17, 2020 - link
Danbob is confused by the fact that Apple doesn't use the ARM designs. He assumes that lack of use results from lack of access.RedGreenBlue - Tuesday, November 17, 2020 - link
They still based some designs closely to the generic ones. I think the A7 was shown to be only slightly modified in Anandtech’s review (the first 64-bit with Arm-v8(?))