Initial reviews of JavaScript performance benchmarks show the iPhone XS and iPhone XS max having better performance than even an iMac Pro with the Speedometer 2.0 benchmark, which compares performance in real-world framework loading scenarios.
David Heinemeier Hansson, creator of Ruby on Rails, founder & CTO at Basecamp, started a discussion on Twitter:
The iPhone XS is faster than an iMac Pro on the Speedometer 2.0 JavaScript benchmark. It’s the fastest device I’ve ever tested. Insane 45% jump over the iPhone 8/X chip. How does Apple do it?!
This tweet led to significant speculation on how this performance improvement is possible.
Rafael Oliveira, CTO of curiosity.ai, remarked that Apple seems to optimize their JS compiler for ARM far more than they do for the x86 found in Mac desktops:
But that's the point - Apple doesn't seem to optimize the x86 Safari that much anymore, but their ARM JS compiler gets a lot of love... Not saying their CPUs aren't impressive, just that the difference seems to be exaggerated when benchmarking JS.
Software engineer Greg Parker pointed out that the latest ARM instruction sets, ARMv8.3-A, make specific improvements to JavaScript performance:
ARMv8.3 adds a new float-to-int instruction with errors, and out-of-range values handled the way that JavaScript wants. The previous instructions to get JavaScript's semantics were much slower. JavaScript's numbers are double by default, so it needs this conversion a lot.
ARM did indeed release many updates known as ARMv8.3-A, including improvements to JavaScript data type conversion:
JavaScript uses the double-precision floating-point format for all numbers. However, it needs to convert this common number format to 32-bit integers in order to perform bit-wise operations. Conversions from double-precision float to integer, as well as the need to check if the number converted really was an integer, are therefore relatively common occurrences.
The ARMv8.3-A instructions help convert a double-precision floating-point number to a signed 32-bit integer to improve performance.
However, it turns out that this was not the reason for the performance improvement, as software engineer Saam Barati explains that iOS 12 Safari does not yet leverage these instructions.
Since the initial reports, an improvement to leverage ARMv8.3-A instructions has landed in WebKit nightlies and is expected in future versions of Safari. Most notably, Barati notes improvements to performance in various JetStream2 test results:
15% better on stanford-crypto-aes
30% better on stanford-crypto-pbkf2
97% better on stanford-crypto-sha256
Overall, the fix is expected to add an overall 0.5-2% performance improvement beyond the current version of Safari without support for ARMv8.3-A.
Per a detailed iPhone XS performance report from Anandtech, the most likely reason for the significant improvement in JavaScript performance is the new memory subsystem:
403.gcc partly, and most valid for 429.mcf, 471.omnetpp, 473.Astar and 483.xalancbmk are sensible to the memory subsystem and this is where the A12 just has astounding performance gains from 30 to 42%. It’s clear that the new cache hierarchy and memory subsystem has greatly paid off here as Apple was able to pull off one of the most major performance jumps in recent generations.
So while the ARM improvements are useful to computationally expensive JavaScript operations, they are not as significant as the memory subsystem improvements.
As a result, many are asking when Apple will switch from Intel to ARM for future desktop and laptop Macs, and will this result in a similar improvement over today's performance?
