How is it that reference counting is faster on Apple silicon Intel translation than on Intel?

Question

I can't find the exact tweet, but it was stated by Apple engineers that the retain and release operations are faster on Intel x86 translation than on standard Intel x86.

Answer 1

Rosetta 2 employs Just-In-Time compilation with dynamic optimization, just like, for example, the Oracle HotSpot JVM (and most others as well, e.g. IBM J9 / Eclipse OpenJ9), the Microsoft .NET CLR, all mainstream ECMAScript implementations (GraalJS, V8, SpiderMonkey, JavaScriptCore), the PyPy, GraalPython, IronPython, and Jython Python implementations, the Rubinius, IronRuby, JRuby, TruffleRuby, and YARV Ruby implementations, and many more.

Since a dynamic optimizer can simply inspect the current program state and observe the program behavior, impossibility results for static analysis, such as the Undecidability of the Halting Problem or Rice's Theorem do not apply, and thus the Rosetta 2 dynamic optimizer can perform optimizations that the original Swift or Objective-C compiler could not. So, it is not surprising that the code may be more optimized and thus may be faster for certain types of operations.

You would probably be able to achieve the same by running a modified version of Rosetta 2 that compiles from AMD64 to AMD64 on an Intel Mac, or a modified version that compiles from AArm64 to AArm64 on an Apple Silicon Mac, or by changing Swift and Objective-C from an ahead-of-time compiled implementation to a JIT-compiled implementation.

The fact that JIT compilation with dynamic, speculative, and adaptive optimizations can yield large performance benefits has long been known in the dynamic language communities, especially Smalltalk and Lisp. (For example, Oracle HostSpot JVM is actually just a modified Smalltalk VM, IBM J9 was built by IBM's Smalltalk team based on their Smalltalk VM, Google V8 is based on a Smalltalk VM (actually the same one as Oracle HotSpot JVM is).)

But in the late 1990s, for the first time, the knowledge also spread in the C, C++, and assembly communities as well as the CPU community. Intel and HP were working on a new CPU architecture called IA-64, which would be a replacement for HP's PA-RISC architecture as well as Intel's IA-32 architecture (at least on servers and workstations). The CPU bus was kept mostly compatible with PA-RISC, so that it could be used as a drop-in replacement for HP mainframes, but of course, the ISA was completely different.

So, in order to enable their customers a smooth transition from PA-RISC to IA-64, HP developed a dynamic binary translator based on JIT compilation with dynamic optimization. They wanted to benchmark this translation system, but there weren't any IA-64 chips yet. However, they realized, that if they built a PA-RISC backend for the translator, they could still benchmark it, since it would still do all the same work: parse the PA-RISC binary, analyze it, optimize, and then generate optimized machine code, the only difference being that the generated machine code is also PA-RISC instead of IA-64.

In fact, because the frontend and backend are the same, they could make a direct comparison of code running natively in PA-RISC, and code running in the translator on the exact same system, which would allow them to accurately measure the overhead and slowdown of the translator. And so they did measure it, and they found that the slowdown was … negative! In other words, it was a speedup.

This was the well-known Dynamo project.

So, in short: dynamic optimization can perform optimizations that static optimization cannot, so it is at least believable that the statement could actually be true.

Answer 2

First, the M1 processors seem to have significantly higher speed than equivalent Intel processors, so retain / release would run faster after translating Intel to ARM code unless the translated code was significantly worse.

But these two operations are used an awful lot. And Apple has written the code for them, so it's quite possible that they don't get translated using the general purpose translator, but that the translator will recognise the code and translate it to the optimal ARM code for this purpose.

The same is likely true in other situations; if your code calls low-level code written by Apple, that code might be not translated, but directly replaced with equivalent optimised ARM code. And if you look at how much money Apple makes from devices with ARM processors vs. devices with Intel processors, the existing ARM code might be better than the existing Intel code.

And lots of libraries are part of the OS itself, like the Standard C, C++, Objective-C and Swift libraries, so they are not going to be translated at all, but the original ARM libraries will be used.

PS. Today some benchmark results have released comparing Macs with M1 processor running emulated x86 code with Intel Macs - the M1 processor beats any Intel-based Mac in single threaded performance.