
Introducing SIMD.js - rnyman
https://hacks.mozilla.org/2014/10/introducing-simd-js/
======
general_failure
Contrary to popular opinion, I think this is actually a terrible idea. By
doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we
shouldn't standardize on API for things which are so low level and this is
really like an implementation detail in the virtual machine.

I would suggest two alternate approaches:

1\. First come with a standard SIMD specification across CPUs. In some ways
like the GL specification (for GPU) or even the webrtc stuff (for p2p
connections). Once you have done that, define a JS API.

2\. Identify proper use cases. The example are quite bogus currently. They
show a mandelbrot. Well, all this is done in the GPU. Image manipulation is
done best with css level filters. Once we identify the use cases, we can them
maybe add APIs to specifically address them if it's important for the web in
general.

In it's current form, this is really a 'because we can' API. Where does this
end? What if we just expose raw socket and networking API instead of a webrtc
style API? What about pixel manipulation of images?

Also see: [http://www.mail-archive.com/webkit-
dev@lists.webkit.org/msg2...](http://www.mail-archive.com/webkit-
dev@lists.webkit.org/msg25237.html). The apple guys are saying they can do all
this even without the API.

~~~
simonster
I'm also not so sure about this. I admit to having limited compiler design
experience, but the WebKit FTL guys do, and they seem to be saying that many
things that can be done with SIMD primitives can be done better with automatic
vectorization, since you can specialize code for the specific processor it's
being executed on. On top of that, it's easier for the programmer if they can
write ordinary code and get SIMD performance.

Are there cases where algorithms simply cannot be expressed in a way that
automatic vectorization could transform them into SIMD instructions? Or is
this just a way to avoid implementing automatic vectorization in JavaScript
engines?

~~~
pcwalton
Autovectorization has been an area of intense compiler effort for a decade or
more and by and large the primary customers of it (games, video codecs, etc.)
prefer the intrinsics. It's perceived as too unreliable and brittle to be
relied upon, and it's easy to see why: given a choice between having to think
about what the compiler's alias analysis, overflow analysis, loop trip count
analysis, etc. will do and just writing an intrinsic and calling it a day,
programmers will choose the latter.

This applies regardless of how good the autovectorization really is: it's in a
weird catch-22 kind of space where adding more and more features to your
autovectorizer can actually _reduce_ its perceived reliability, by making the
answer to "will this vectorize?" harder and harder for a programmer to answer
at a glance. <xmmintrin.h> has a lot of problems, but it's _reliable_ , and at
the end of the day that's what history has shown that game devs and video
codec authors want.

~~~
simonster
I appreciate that autovectorization is hard to do well. However, I think the
world of JS is different from the world of C/C++. JS optimization is already
pretty unpredictable, since the language is dynamic (both in terms of typing
and e.g. object memory layout, with the exception of typed arrays); JS
primitives are farther from the metal; the optimizations that JS engines
perform are implementation-specific, rarely well-documented and always in
flux; and it's difficult to see what machine code actually runs for a given JS
function. SIMD instructions may make some sense for JS as a compiler target,
but they seem to make less sense for JS as a language that doesn't have
integers or 32-bit floating point numbers. On top of that, most users of
vectorization are targeting a specific architecture or even CPU, whereas JS
code is meant to run anywhere. It doesn't seem like there's been much work to
alter the language or tools to make it easier for programmers to reason about
other sources of unpredictability, so why so much emphasis on SIMD?

I'll admit some ignorance here, but it also seems to me that a JIT may also
have some advantages WRT autovectorization as compared with a static compiler,
since you can collect runtime information about aliasing and loop trip count
before choosing to vectorize. But if the point is to make performance easier
to reason about, why not start with the rest of the language before worrying
about vectorization?

~~~
azakai
> It doesn't seem like there's been much work to alter the language or tools
> to make it easier for programmers to reason about other sources of
> unpredictability, so why so much emphasis on SIMD?

But there certainly have been such efforts! Standards bodies have added
features like Typed Arrays, Math.fround, etc., and work is ongoing on Classes,
Typed Objects, and Modules. All of those things make performance more
predictable.

There are also better devtools all the time, which help you understand
performance issues better.

And there is also asm.js which aims to make a certain type of JavaScript
extremely predictable.

A final point - the unpredictability you mention is exactly why a SIMD API is
needed. JavaScript is more unpredictable than C and C#, but even those have
added SIMD APIs, because even in their predictable worlds, autovectorization
wasn't good enough.

------
jonstewart
Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the
historically awful patchwork of kludges that gets passed onto each generation
to kludge anew which also runs the entire world. JavaScript: we don't have
integers, but, dammit, we have vector instructions. FML.

Maybe it's not too late to take up painting.

~~~
ep103
>SIMD.js is originally derived from the Dart SIMD specification

I am so ungodly sick of Google pushing DART technologies everywhere. I really
am starting to think their strategy is embrace, enhance, exterminate.

~~~
pcwalton
If you don't like Dart, then you should actually be in favor of this move. It
negates what was previously an advantage of Dart over JavaScript.

------
asb
Now I'm just waiting for int64.js, which should appear when ES7 value objects
come along [http://www.slideshare.net/BrendanEich/value-
objects2](http://www.slideshare.net/BrendanEich/value-objects2)

~~~
bobajeff
Same here. I'm also looking forward to asm.js being a target for JVM, CLR and
other garbage collected languages through Typed Objects.
[https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#...](https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Proposed_future_JS_features_that_would_be_useful_to_asm.js)

Also, am hoping 'JavaScript Shared Memory, Atomics, and Locks' gets accepted
by TC-39.
[https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEq...](https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing&pli=1)

------
IvanK_net
What we really need is to spread WebCL -
[https://www.khronos.org/registry/webcl/specs/1.0.0/](https://www.khronos.org/registry/webcl/specs/1.0.0/)

1\. It is already standardized language and API. There exist a lot of code for
WebCL.

2\. WebCL engines can run on CPU, they can use all CPU cores, SIMD etc., while
still being a part of web browser (no special drivers required). It will give
us much better performance, than asm.js, SIMD.js, Google's Native Client or
any other "unstandardizible" things.

~~~
ndesaulniers
WebCL is DOA:
[https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30](https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30)

~~~
IvanK_net
Well that's what Microsoft said about Android in 2008. No wonder that Firefox
is loosing popularity, when they refuse to innovate.

~~~
ndesaulniers
I'm taking my crayons and going home!

------
gopalv
Neat, looks like JS is getting SIMD speedups because of fixed type objects.

Would really love to see the speedup on fixed tuple transforms and convolution
algorithms.

When I saw JS speed wars originally, I started writing an adobe curve apply
algorithm in JS, to apply .acv curves live using Canvas, but essentially hit
CPU & shelved it.

[https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine...](https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine.js#L46)

[http://notmysock.org/code/iodine/](http://notmysock.org/code/iodine/)

I want to rewrite it using something like the newly introduced float32x4,
assuming I can read out the images int o RGBA tuples.

Something like a blur would actually be possible once this is fast.

~~~
sunfish
That applycurve function has what appears to be a gather, which is
unfortunately outside of where we expect to be with the initial iteration of
SIMD.js, as there isn't widespread CPU SIMD hardware support for it yet.
However, the brighten function immediately above it, for example, is supported
by features in the SIMD.js spec today.

------
JetSpiegel
It's official, Javascript is the new Assembly. I'll wait for the new Python, I
never liked low level languages.

~~~
quinnirill
I liked the "original" assembly more, at least it was designed for helping
_humans_ to write and read code.

EDIT: That said, this is good news, in a sense.

~~~
espadrine
You make me wonder which assembly you're talking about. x86-64 feels heavy
with legacy designs, many ways to get the same result, common pitfalls
regarding memory management, and some surprising very specific gems to make
some things fast… such as SIMD.

(I know little about other instruction sets.)

~~~
quinnirill
I'm just talking about design goals - the original assembly was introduced so
that people wouldn't have to remember the numeric instructions of the
processor. The instruction sets have been legacy even before that, with slight
improvements occasionally, but at least the target audience was people in the
beginning. With asm.js the target has been compilers to begin with. With most
assembly dialects the instructions have a clear purpose, where as with asm.js
you have arcane rules on what makes what stay as an integer, etc., enough so
that I think most of the group of sane people would prefer writing against
traditional assembly dialects than asm.js.

Maybe that's a good thing, at least then the goal is that people who care
about performance don't write JS. But I'd prefer to just have the compile
target as numbers then since you can't read the result anyway.

------
hajile
And this is why we need to simply switch to LLVM. It gives us a sane bytecode,
allows any language, allows real pre-browser optimization, etc. Mozilla's
moving that direction with Rust and Servo. Google has already experimented
with it via pnacl, and webkit/apple already actively compiles JS to llvm.

For backward compatibility, just use and extend emscripten. As a bonus, this
would allow the DOM interface to be reworked so we can get it right.

~~~
legulere
Well LLVM heavily relies on not having forward compatibility (new versions
spew out LLVM IR that can't be used by older versions) and backward
compatibility is merely an afterthought.

~~~
sanxiyn
Khronos Group standardized LLVM IR 3.2 as SPIR(Standard Portable Intermediate
Representation). It is an existence proof that standardizing LLVM IR is
possible.

[https://www.khronos.org/spir/](https://www.khronos.org/spir/)

~~~
legulere
I actually work a bit with SPIR. They standardized a subset of LLVM IR 3.2 as
SPIR 1.2

SPIR 2.0 on the other hand already is based off LLVM IR 3.4

------
J_Darnley
Where are the Bytex16 types? Or the Wordx8 types? Who the hell is using floats
for every data value?

~~~
cliffbean
They're coming. The initial code for them is written; it's just waiting for a
few other things to get checked in first.

Also, quite a lot of people use floats for every data value.

------
ecesena
Neat! Is anyone playing with js crypto and this new stuff?

