
Intent to implement WASM in v8 - dangoor
https://groups.google.com/forum/#!topic/v8-users/PInzACvS5I4
======
kragen
I was just reflecting on yesterday's hack of my 81 hacks, considering the
possibility of adding an asm.js code generator to it:
[http://canonical.org/~kragen/sw/81hacks/oscarray/notes](http://canonical.org/~kragen/sw/81hacks/oscarray/notes).
Being able to run that code in Chromium as well as Iceweasel would be a big
benefit! Especially if Chromium adds SIMD.js as well (currently only in
Firefox nightly; see [https://blog.mozilla.org/javascript/2015/03/10/state-of-
simd...](https://blog.mozilla.org/javascript/2015/03/10/state-of-simd-js-
performance-in-firefox/) for more details) since that would enable JS code to
generate code at runtime that would get performance several times better than
optimized C, at least for the kinds of graphics, DSP, and machine learning
problems that are easy to implement in SIMD.

SIMD.js still looks pretty half-baked (you can't supply vector arguments to
provide the indexes for shuffling? Really?) but already promising.

~~~
sunfish
Most SIMD hardware instruction sets don't support (dynamic) vector arguments
to provide the indices for shuffling, so it wouldn't be fast if SIMD.js' API
had it.

~~~
mtklein
I'd argue most SIMD hardware instruction sets do support that. x86 has had
pshufb since SSSE3 (most desktop+laptop, and ~all mobile x86), providing an
arbitrary byte shuffle across 16 bytes, and NEON has vtbl, pretty much the
same but limited to 8 bytes of output per instruction.

Now, I will admit that those instructions are not always a good idea
(particularly on mobile x86, where pshufb is often several cycles), and
they're essentially never a good idea when a specialized instruction (e.g.
punpcklbw, vtrn) can do the job.

~~~
ndesaulniers
> x86 has had pshufb since SSSE3

SIMD.js uses SSE2 as the baseline, due to NEON compatibility, though our
implementer and TC39 champion, sunfish, can probably answer more in depth.

~~~
sunfish
It's not just SSE2; SIMD.js also includes things like Int32x4.mul, which is a
little tricky without SSE4.1's pmulld. It's kind of a balancing act between
several concerns. Also, it's a base, and we definitely plan to iterate and add
more features on top of it.

------
_greim_
Since it's v8, does this mean someday certain Node.js modules could be written
in wasm, but still be callable from JS?

~~~
maga
Yes, and it would be interesting to compare WASM with the native Node plugins
performance-wise. Especially looking at how it handles the interaction between
JS and plugins/wasm. AFAIK, right now there are penalties associated with
moving values in and out of V8 when using native plugins. If WASM can avoid
that, native plugins may switch to it.

~~~
z1mm32m4n
This whole conversation just makes me smile at how much truth and more is
coming out of Gary Bernhardt's The Birth and Death of JavaScript[1].

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
TimJYoung
Is this DOM/UI-less ? Everything I've read on WASM so far has indicated that
it would be (initially) similar to web workers and _not_ give access to the
DOM.

~~~
greggman
You can think of wasm as pure assembly language functions you can call.

They can't interact directly with any browser APIs but they can be called from
JavaScript and they can call into JavaScript

Not as isolated as workers

~~~
TimJYoung
Thanks. WASM is going to be very interesting, and I will be modifying our
compiler/transpiler to support it as soon as the DOM access is available.

------
jiyinyiyong
I'm very interested! Will V8 be the first browser engine to ship WASM to
developers?

------
Animats
Somehow, I suspect that WebAssembly will eventually have most of the problems
of Java in the browser.

~~~
Kinnard
Why?

~~~
Animats
Yes, it's supposed to be sandboxed. But

 _" programs which invoke undefined behavior at the source language level may
be compiled into WebAssembly programs which do anything else, including
corrupting the contents of the application heap, calling APIs with arbitrary
parameters, hanging, trapping, or consuming arbitrary amounts of resources
(within the limits)."_ [1]

So now it's possible to hammer on the entire JavaScript API with invalid
parameters. How long before someone finds a hole?

[1]
[https://github.com/WebAssembly/design/issues/205](https://github.com/WebAssembly/design/issues/205)

~~~
mccr8
That quote is talking about (untrusted) compilers that translate from C/C++
with undefined behavior to WebAssembly programs. The latter would still have a
defined behavior.

People already "hammer on the entire JavaScript API with invalid parameters".
That's what fuzzing is, and yes, it does find implementation errors which can
lead to security problems.

