3 ms·

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

by Arelius 13y ago

deleted 13y ago
[deleted]
- btilly 13y ago
  Grandparent may be saying that, but that's not true. The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those. Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed the browser. Human written code would not have those problems.
  - hollerith 13y ago
    Thanks for pointing out my error. (Hope you don't mind that I deleted my comment.)
    - btilly 13y ago
      Usually in a case like that I'd edit it to add an update admitting the correction. The rest of what you said was quite useful for people who didn't want to read a long article.
kibibu 13y ago
Check this out (from the asm.js spec) function add1(x) { x = x|0; // x : int return (x+1)|0; } This declares x to be an int in asm.js, which allows a bunch of optimizations. In a non-asm.js engine, it is an extra 2 operations. It's not difficult to believe that a non-asm.js engine would be slower with the type annotations than without, although I don't have any performance numbers to check.
- azakai 13y ago
  It's not an extra two operations. An optimizing JIT like CrankShaft or IonMonkey can remove the first |0 operation in code paths where it is not needed (that is, where you call it with an integer), and can remove the second |0 even more easily by simple inference - in fact, the second |0 allows the JIT to emit a 32-bit addition, with no overflow checks. So it can make code faster, with or without asm.js.
  - kibibu 13y ago
    Count the number of times you wrote "can" vs how many times you typed "does". Similar stuff happens with C++ compilers all the time, where certain code "can" help the compiler but, in practice, doesn't always. The linked benchmarks do show a slowdown with asm.js in IE10. Whether this is due to type annotations or something else I don't know.
    - azakai 13y ago
      Are you saying it's as unpredictable as C++ performance then? I'll take that ;) I wrote "can" because there are no guarantees, but in practice, this is definitely done in Firefox and Chrome. See http://www.arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://www.arewefastyet.com/#machine=11&view=breakdown&#... - they don't get that close to native speed without such optimizations. Not sure what is going on in IE10, but I am more curious about IE11.

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

by Arelius 13y ago

> its slightly slower (a few %) than regular JS on browsers without asm.js support You sure you meant what you said here?

deleted 13y ago

[deleted]

btilly 13y ago
Grandparent may be saying that, but that's not true. The comparison that is close is code produced from a C compiler for normal JS, versus code produced from the same compiler and code for asm.js. BUT code that would be written by a human would be expected to be more compact and run much faster than either of those. Furthermore the code that they wrote would not run on all browsers, and if it did run often crashed the browser. Human written code would not have those problems.
- hollerith 13y ago
  Thanks for pointing out my error. (Hope you don't mind that I deleted my comment.)
  - btilly 13y ago
    Usually in a case like that I'd edit it to add an update admitting the correction. The rest of what you said was quite useful for people who didn't want to read a long article.

kibibu 13y ago

Check this out (from the asm.js spec) function add1(x) { x = x|0; // x : int return (x+1)|0; } This declares x to be an int in asm.js, which allows a bunch of optimizations. In a non-asm.js engine, it is an extra 2 operations. It's not difficult to believe that a non-asm.js engine would be slower with the type annotations than without, although I don't have any performance numbers to check.

azakai 13y ago
It's not an extra two operations. An optimizing JIT like CrankShaft or IonMonkey can remove the first |0 operation in code paths where it is not needed (that is, where you call it with an integer), and can remove the second |0 even more easily by simple inference - in fact, the second |0 allows the JIT to emit a 32-bit addition, with no overflow checks. So it can make code faster, with or without asm.js.
- kibibu 13y ago
  Count the number of times you wrote "can" vs how many times you typed "does". Similar stuff happens with C++ compilers all the time, where certain code "can" help the compiler but, in practice, doesn't always. The linked benchmarks do show a slowdown with asm.js in IE10. Whether this is due to type annotations or something else I don't know.
  - azakai 13y ago
    Are you saying it's as unpredictable as C++ performance then? I'll take that ;) I wrote "can" because there are no guarantees, but in practice, this is definitely done in Firefox and Chrome. See http://www.arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-ubench http://www.arewefastyet.com/#machine=11&view=breakdown&#... - they don't get that close to native speed without such optimizations. Not sure what is going on in IE10, but I am more curious about IE11.