7 ms·

@steipete puts it pretty well: JavaScript really made it. We now tweak CPUs to make it faster. https://twitter.com/steipete/status/1047415826083729408 https://

@steipete puts it pretty well: JavaScript really made it. We now tweak CPUs to make it faster. https://twitter.com/steipete/status/1047415826083729408 https://twitter.com/steipete/status/1047415826083729408

userbinator 8y ago
ARM did something similar with Java before: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle I would not be surprised if they come up with a way of directly executing WASM or such. (And then the possibilities for security exploits become a lot more interesting...)
- naphthalene 8y ago
  Wasn't ARM's choice directly related to (or maybe influenced by) Android though?
  - baybal2 8y ago
    No, it was influenced by J2ME
  - ibrahima 8y ago
    Jazelle predates Android.
- nonsince 8y ago
  The only thing they could do for Wasm would be to allow sub-process-granularity hardware memory access virtualisation and easily-enforceable float rounding modes afaik
tzs 8y ago
That was a trick Dave Fotland used in the '80s to make his Go program, "Many Faces of Go", faster. He donated some key code from his evaluation function to SPEC and they used it as one of the parts in the SPEC integer CPU benchmarks. CPU makers tweaked CPUs to do well on those benchmarks, and hence on his code.
- acemarke 8y ago
  I had to read that comment a couple times before I realized you were referring to the board game and not the programming language :)
- kbenson 8y ago
  That's a wonderful bit of social engineering.
- codinghorror 8y ago
  I highly recommend this article in that same vein http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/ http://benediktmeurer.de/2016/12/16/the-truth-about-traditio... This is when Chrome on Android finally started to turn a corner, they've done a fantastic job. JS perf has increased 50% from 2016 to 2018 in Chrome/Android. Sadly Android is still hamstrung by extremely mediocre Qualcomm SoCs but they've made huge strides on the software side.
- chaboud 8y ago
  I've talked with him about those days... Though I haven't chatted with him about Go since AlphaGo flipped the whole world over. I worked very hard on pulling the same trick at Sony. We'd made Vegas scriptable, and, once it was part of Bapco's Sysmark, we received immense support from chip vendors. Machines, engineers, tools, instructions added to instruction sets... It was a nutty time. Of course, the biggest wins worked everywhere, like the 6755399441055744 single precision rounding trick, or the use of memory mapped file regions to cache the rendering tree. Still, becoming part of a performance benchmark is a great way to get attention.
- nashashmi 8y ago
  I was confused by the words "Go Program" "in the '80s" in one sentence. OP is talking here about the Go board game played by a computer AI. Not talking about Go language.
ihuman 8y ago
"The Birth and Death of Javascript" becomes more and more real https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- enraged_camel 8y ago
  I like the part about the Bay Area being a radioactive wasteland. :)
  - Analemma_ 8y ago
    Technically, he only said it was an "Exclusion Zone", so it could refer to real estate prices in the 2035 Bay Area for non-quadrillionaires.
  - RightMillennial 8y ago
    Fallout: New Francisco
    - ndesaulniers 8y ago
      We're firmly within NCR territory here.
      - IgorPartola 8y ago
        The Hobologists send their regards.
- earenndil 8y ago
  I still don't buy it. Javascript might buy a 4% performance improvement, but the increased resource usage makes that impractical for most scenarios. For server use, the increased wear makes it cheaper to buy more computers and have them last longer. For application use, performance is not relevant enough to make it interesting. So really the only possible application is video games. EDIT: before people accuse me of making a false dichotomy: I acknowledge that there are other uses for computers, but am unable to think of any others where the increased resource consumption would be worth it. Another thing: cell phones, the battery would drain much more quickly if everything were a webapp. Perhaps video game consoles will switch to such a JIT, though...
mortenjorck 8y ago
In retrospect, it’s almost surprising that there was never a push for hardware acceleration of common JavaScript operations.
- wruza 8y ago
  Why? It is not special in any way. It is area in which you can be special only in special olympics sense. The new instruction doesn’t make anything new, it is just different and serves no purpose for 99.9% of users.
  - djrogers 8y ago
    100% of users of mobile devices use JavaScript. 98% of them use it heavily in their web browsers. To ignore it, or try to pass it off as insignificant, is folly.
    - wruza 8y ago
      Oh, words go playing. Who uses that modulo 2^32 thing heavily in their browsers? Folly is wasting world’s resources on ineffective crappy implementation of unused features. Obviously it seems reasonable to fix hw. If I were Apple, I wouldn’t even think to reason with js socium.
      - millstone 8y ago
        ALU ops are cheap, interconnects are expensive. Curse JS for scatter-gather, not for its FCVTZS details. (Though now I can't explain the magnitude of the win...fine, curse JS for both.)
wruza 8y ago
Apple now tweaks cpus to make their js engine faster. This doesn’t sound as cool, but is more true. I’m also not sure if that’s a “win” in general. Dynamic languages used doubles since forever now and to me, either A) cpu makers sleep for too long, B) js is such a historical mess that fixing it in hw is reasonable now. It is interesting how e.g. LuaJIT may benefit from that, but unfortunately it is [formally] unavailable on appstore because of licensing restrictions. As are non-apple fast js engines.
- eridius 8y ago
  Any JS engine on an ARMv8.3 chip could benefit from this instruction, not just Apple's JS engine. Sure you can't put other JS engines on an iPhone (at least not without jailbreaking), but this says ARMv8.3 adds it, not "Apple's specific CPU", though I have no idea if there are any other ARMv8.3 chips at the moment. As for other languages that use Doubles, this instruction isn't for general-purpose Doubles. CPUs already handle those. This instruction specifically implements the exact semantics that JavaScript wants. Now, maybe some other dynamic languages would want the same semantics when converting Doubles to ints, I don't know. But it's by no means a given that they would. Also, most languages don't use Doubles for all numeric types anyway.

userbinator 8y ago

ARM did something similar with Java before: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle I would not be surprised if they come up with a way of directly executing WASM or such. (And then the possibilities for security exploits become a lot more interesting...)

naphthalene 8y ago
Wasn't ARM's choice directly related to (or maybe influenced by) Android though?
- baybal2 8y ago
  No, it was influenced by J2ME
- ibrahima 8y ago
  Jazelle predates Android.
nonsince 8y ago
The only thing they could do for Wasm would be to allow sub-process-granularity hardware memory access virtualisation and easily-enforceable float rounding modes afaik

tzs 8y ago

That was a trick Dave Fotland used in the '80s to make his Go program, "Many Faces of Go", faster. He donated some key code from his evaluation function to SPEC and they used it as one of the parts in the SPEC integer CPU benchmarks. CPU makers tweaked CPUs to do well on those benchmarks, and hence on his code.

acemarke 8y ago
I had to read that comment a couple times before I realized you were referring to the board game and not the programming language :)
kbenson 8y ago
That's a wonderful bit of social engineering.
codinghorror 8y ago
I highly recommend this article in that same vein http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/ http://benediktmeurer.de/2016/12/16/the-truth-about-traditio... This is when Chrome on Android finally started to turn a corner, they've done a fantastic job. JS perf has increased 50% from 2016 to 2018 in Chrome/Android. Sadly Android is still hamstrung by extremely mediocre Qualcomm SoCs but they've made huge strides on the software side.
chaboud 8y ago
I've talked with him about those days... Though I haven't chatted with him about Go since AlphaGo flipped the whole world over. I worked very hard on pulling the same trick at Sony. We'd made Vegas scriptable, and, once it was part of Bapco's Sysmark, we received immense support from chip vendors. Machines, engineers, tools, instructions added to instruction sets... It was a nutty time. Of course, the biggest wins worked everywhere, like the 6755399441055744 single precision rounding trick, or the use of memory mapped file regions to cache the rendering tree. Still, becoming part of a performance benchmark is a great way to get attention.
nashashmi 8y ago
I was confused by the words "Go Program" "in the '80s" in one sentence. OP is talking here about the Go board game played by a computer AI. Not talking about Go language.

ihuman 8y ago

"The Birth and Death of Javascript" becomes more and more real https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

enraged_camel 8y ago
I like the part about the Bay Area being a radioactive wasteland. :)
- Analemma_ 8y ago
  Technically, he only said it was an "Exclusion Zone", so it could refer to real estate prices in the 2035 Bay Area for non-quadrillionaires.
- RightMillennial 8y ago
  Fallout: New Francisco
  - ndesaulniers 8y ago
    We're firmly within NCR territory here.
    - IgorPartola 8y ago
      The Hobologists send their regards.
earenndil 8y ago
I still don't buy it. Javascript might buy a 4% performance improvement, but the increased resource usage makes that impractical for most scenarios. For server use, the increased wear makes it cheaper to buy more computers and have them last longer. For application use, performance is not relevant enough to make it interesting. So really the only possible application is video games. EDIT: before people accuse me of making a false dichotomy: I acknowledge that there are other uses for computers, but am unable to think of any others where the increased resource consumption would be worth it. Another thing: cell phones, the battery would drain much more quickly if everything were a webapp. Perhaps video game consoles will switch to such a JIT, though...

mortenjorck 8y ago

In retrospect, it’s almost surprising that there was never a push for hardware acceleration of common JavaScript operations.

wruza 8y ago
Why? It is not special in any way. It is area in which you can be special only in special olympics sense. The new instruction doesn’t make anything new, it is just different and serves no purpose for 99.9% of users.
- djrogers 8y ago
  100% of users of mobile devices use JavaScript. 98% of them use it heavily in their web browsers. To ignore it, or try to pass it off as insignificant, is folly.
  - wruza 8y ago
    Oh, words go playing. Who uses that modulo 2^32 thing heavily in their browsers? Folly is wasting world’s resources on ineffective crappy implementation of unused features. Obviously it seems reasonable to fix hw. If I were Apple, I wouldn’t even think to reason with js socium.
    - millstone 8y ago
      ALU ops are cheap, interconnects are expensive. Curse JS for scatter-gather, not for its FCVTZS details. (Though now I can't explain the magnitude of the win...fine, curse JS for both.)

wruza 8y ago

Apple now tweaks cpus to make their js engine faster. This doesn’t sound as cool, but is more true. I’m also not sure if that’s a “win” in general. Dynamic languages used doubles since forever now and to me, either A) cpu makers sleep for too long, B) js is such a historical mess that fixing it in hw is reasonable now. It is interesting how e.g. LuaJIT may benefit from that, but unfortunately it is [formally] unavailable on appstore because of licensing restrictions. As are non-apple fast js engines.

eridius 8y ago
Any JS engine on an ARMv8.3 chip could benefit from this instruction, not just Apple's JS engine. Sure you can't put other JS engines on an iPhone (at least not without jailbreaking), but this says ARMv8.3 adds it, not "Apple's specific CPU", though I have no idea if there are any other ARMv8.3 chips at the moment. As for other languages that use Doubles, this instruction isn't for general-purpose Doubles. CPUs already handle those. This instruction specifically implements the exact semantics that JavaScript wants. Now, maybe some other dynamic languages would want the same semantics when converting Doubles to ints, I don't know. But it's by no means a given that they would. Also, most languages don't use Doubles for all numeric types anyway.