5 ms·

tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native. Also its slightly slower (a few %) than regu

by zobzu 13y ago

tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native. Also its slightly slower (a few %) than regular JS on browsers without asm.js support.

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.
capisce 13y ago
"within 2x the speed of native" Of crippled native, with things like SIMD instructions disabled.
- acdha 13y ago
  With some optimizations unrealized: it's not like everything can use SIMD or that all problems which could theoretically use SIMD actually benefit. Comparing scalar code is still useful for the vast majority of programs executed.
  - azakai 13y ago
    Furthermore, explicit SIMD code (for example, using SSE functions) is not portable. The comparison here was portable C/C++ to portable asm.js.
    - capisce 13y ago
      First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors http://clang.llvm.org/docs/LanguageExtensions.html#vectors-a... Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) and in addition SSE is used even for scalar floating point operations these days. It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases. Last, web workers are less flexible than native multithreading with shared memory between threads and atomic instructions / mutexes etc. These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL.
      - azakai 13y ago
        > First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code It's portable in one sense, but not another - it doesn't work in other compilers like MSVC, which was used in this article. > Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) Yes, if the native compiler did auto vectorization here, it helped it. asm.js still did very well though, so I suspect auto vectorization could not be achieved. > and in addition SSE is used even for scalar floating point operations these days. Yes, in both native compilers and JS engines. Likely SSE was used in both sides of the comparison here. > It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases. True, we are investigating that. Note that you can in some cases optimize double precision operations into single precision ones, even without explicit syntax. > These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL. If we are talking about the current state now, then PNaCl does not support SIMD either. If we are talking about eventually, then eventually JS might gain those things too.

by zobzu 13y ago

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.

capisce 13y ago

"within 2x the speed of native" Of crippled native, with things like SIMD instructions disabled.

acdha 13y ago
With some optimizations unrealized: it's not like everything can use SIMD or that all problems which could theoretically use SIMD actually benefit. Comparing scalar code is still useful for the vast majority of programs executed.
- azakai 13y ago
  Furthermore, explicit SIMD code (for example, using SSE functions) is not portable. The comparison here was portable C/C++ to portable asm.js.
  - capisce 13y ago
    First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors http://clang.llvm.org/docs/LanguageExtensions.html#vectors-a... Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) and in addition SSE is used even for scalar floating point operations these days. It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases. Last, web workers are less flexible than native multithreading with shared memory between threads and atomic instructions / mutexes etc. These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL.
    - azakai 13y ago
      > First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code It's portable in one sense, but not another - it doesn't work in other compilers like MSVC, which was used in this article. > Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) Yes, if the native compiler did auto vectorization here, it helped it. asm.js still did very well though, so I suspect auto vectorization could not be achieved. > and in addition SSE is used even for scalar floating point operations these days. Yes, in both native compilers and JS engines. Likely SSE was used in both sides of the comparison here. > It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases. True, we are investigating that. Note that you can in some cases optimize double precision operations into single precision ones, even without explicit syntax. > These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL. If we are talking about the current state now, then PNaCl does not support SIMD either. If we are talking about eventually, then eventually JS might gain those things too.