

The state of SIMD.js performance in Firefox - leo2urlevan
https://blog.mozilla.org/javascript/2015/03/10/state-of-simd-js-performance-in-firefox/

======
wongarsu
I think using the polyfill as a baseline in the benchmark is misleading. Of
course implementing SIMD is faster than emulating it in JavaScript, but nobody
cares about that. What everyone is interested in is: How much faster is their
SIMD implementation over a normal everyday non-SIMD implementation of the same
algorithm. The whole article doesn't even acknowledge that question.

Given that SIMD should bring about a 4 times speedup and yet the polyfill is
17 times slower than the Ion SIMD version and 40 times slower than the asm.js
SIMD version, it seem likely that an implementation of the same algorithm
without SIMD or polyfill would vastly outperform the polyfill too.

~~~
TazeTSchnitzel
I was going to say the same. A polyfill will be more complex than, say:

    
    
      a[0] *= b[0];
      a[1] *= b[1];
      a[2] *= b[2];
      a[3] *= b[3];

------
eggy
Great news and work. Does this mean with C++, Emscripten and ionmonkey we can
do serious array work on the web? I was playing with Dart a year ago for the
very reason of having SIMD available for speedups, but Dart syntax was too
'Java' for me. I don't program for a living, but for fun. I have been studying
J for over a year, and APL recently. They are mind-blowing, and it is
interesting to see old ideas take new footholds given access to GPUs and talk
of vector processors. Julia is on this road too. Arrays are the bread and
butter of the array languages, and even though J runs in an interpreter, it is
mighty fast.

------
noiv
I like the idea, that JS developer who keep their types straight are rewarded
with performance, without introducing "compiler flags".

------
agentultra
The boxing optimizations are really interesting. Great work, mozilla team!

------
higherpurpose
When is the ARM support coming?

