
Latest Revision to ARM Instruction Set Includes Optimizations for JavaScript - mariuz
https://daringfireball.net/linked/2018/10/11/arm-v83-javascript
======
adrianmonk
Previously discussed here:

[https://news.ycombinator.com/item?id=18163433](https://news.ycombinator.com/item?id=18163433)

------
hajile
That seems a little hyperbolic. Jazelle DBX is an example of "optimized for X
language".

This instruction disproportionately helps dynamic languages that convert
between int and float (of which JS is definitely most popular), but basically
every program that does casting from float to int stands to benefit. That's
much better design in my opinion.

~~~
pm215
The insn is definitely js-specific though. The architecture has int-float
conversion insns already which work fine for the purposes of almost all
languages (dynamic or not); but js requires some specific oddball semantics
which this new insn provides.

There are some details in this 2016 blogpost --
[https://community.arm.com/processors/b/blog/posts/armv8-a-ar...](https://community.arm.com/processors/b/blog/posts/armv8-a-architecture-2016-additions)

------
wasmbird
This "the new iPhone is insanely fast at Javascript" story needs to die. It
has always been wrong conclusions drawn from the wrong benchmarks. Speedometer
is a _DOM benchmark_ with very little actual Javascript weight. DOM
performance on mobile Safari is relatively good, considering that the DOM in
general is a performance trainwreck. Apple has really done a good job
optimizing this so that the "modern web" runs on their devices in an
acceptable fashion. It probably has a lot to do with efficient GPU
interfacing.

Furthermore, it is impossible to properly benchmark _any_ JIT language on a
non-jailbroken iOS device, because JIT is not allowed on iOS, only Apple's
implementations like JavaScriptCore are available. It's pointless to make such
benchmarks and draw conclusions about the hardware. Even if you benchmarked
JavaScriptCore on different platforms, it wouldn't necessarily be fair,
because you don't know how much more effort went e.g. into the ARM backend.

~~~
sitkack
One an run a JIT on an iOS device, it is that the app will get denied on
submission. So it would be _possible_ to benchmark a JITed language on iOS.
There are a ton of other ARM targets that could be used as well.

~~~
wasmbird
You can't make a page executable on iOS, which is an OS-level security measure
that also rules out JIT compilation.

Separate from that, apps that download and run scripts may or may not be
rejected based on App Store terms.

