13 ms·

> "There are several theories as to why the M1 does so well on on JavaScript benchmarks." A major reason it does so well is the native Javascript support added

> "There are several theories as to why the M1 does so well on on JavaScript benchmarks." A major reason it does so well is the native Javascript support added in ARMv8.3-A. Specifically, FJCVTZS (Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero)[1] which is a Javascript-specific variant of FCVTZS implementing the overflow and exception handling behaviour that Javascript wants. Javascript needs to do these conversions a lot, since it doesn't have integer types, and it's much faster to have it implemented in silicon rather than using the old instructions and having to handle the overflow/error checking. [1] https://developer.arm.com/documentation/100076/0100/a64-instruction-set-reference/a64-floating-point-instructions/fjcvtzs https://developer.arm.com/documentation/100076/0100/a64-inst...

GeekyBear 6y ago
People who were looking for a root cause of the iOS JavaScript performance advantage have been pointing to that instruction as "the" reason before it was even used by Safari. https://mobile.twitter.com/saambarati/status/1049202132522479616 https://mobile.twitter.com/saambarati/status/104920213252247... I'm sure it doesn't hurt, but the performance advantage predates the instruction's use. Here's another theory. >Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12. https://twitter.com/andreif7/status/1307420010177007625 https://twitter.com/andreif7/status/1307420010177007625
- marmaduke 6y ago
  the second theory seems better in my experience. I pulled a few js benchmarks and ran on native Safari on m1 vs rosetta2 node and the rosetta2+node is significantly faster, suggested the instruction set is not the key.
gpderetta 6y ago
As far as I understand that instruction is needed to get x86 FP semantics on ARM. I.e it doesn't make JS faster but just not as slow as it would otherwise be. Also apparently most JS engines do not actually use the FP unit but can do most computations on the integer units (unless is really FP math) which normally have much lower latency (but also lower bandwidth).

GeekyBear 6y ago

People who were looking for a root cause of the iOS JavaScript performance advantage have been pointing to that instruction as "the" reason before it was even used by Safari. https://mobile.twitter.com/saambarati/status/1049202132522479616 https://mobile.twitter.com/saambarati/status/104920213252247... I'm sure it doesn't hurt, but the performance advantage predates the instruction's use. Here's another theory. >Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12. https://twitter.com/andreif7/status/1307420010177007625 https://twitter.com/andreif7/status/1307420010177007625

marmaduke 6y ago
the second theory seems better in my experience. I pulled a few js benchmarks and ran on native Safari on m1 vs rosetta2 node and the rosetta2+node is significantly faster, suggested the instruction set is not the key.

gpderetta 6y ago

As far as I understand that instruction is needed to get x86 FP semantics on ARM. I.e it doesn't make JS faster but just not as slow as it would otherwise be. Also apparently most JS engines do not actually use the FP unit but can do most computations on the integer units (unless is really FP math) which normally have much lower latency (but also lower bandwidth).