
A Little on V8 and WebAssembly [pdf] - rspivak
https://ia601503.us.archive.org/32/items/vmss16/titzer.pdf
======
bobajeff
Does anybody know the status of Clang/llvm's webassembly backend? I haven't
heard much of anything about its progress recently.

~~~
azakai
It's still not ready for general usage. On real-world codebases it has
correctness issues that need to be sorted out, and there are missing features
like longjmp and C++ exceptions.

~~~
binji
Right, but it's worth mentioning that no part of WebAssembly is ready for
general usage, as it is not yet released. :)

Just like other components of the technology preview, I think it would be
useful to have interested developers try it out and give feedback in the form
of bug reports -- understanding that things are incomplete and going to
change.

~~~
flohofwoe
Right now testing and giving feedback is still a bit too brittle, since too
many moving parts are involved: my asm.js demos here
([http://floooh.github.io/oryol/](http://floooh.github.io/oryol/)) and here
([http://floooh.github.io/oryol-samples/](http://floooh.github.io/oryol-
samples/)), are all ready for wasm, and sometimes I'm putting wasm builds up
there next to asm.js and PNaCl, but it's hard to automate the build like for
asm.js and PNaCl. At the moment there's are bleeding edge build of
Spidermonkey, binaryen and emscripten required to work together. Depending on
the current phase of the moon this works or doesn't work (e.g. right now I'm
having compile problems of Spidermonkey on MacOS 10.12 beta with the Xcode 8
command line tools).

I'm sort of holding back at the moment until emscripten has everything
integrated to build wasm binaries, even if it is not the final LLVM backend.
But I can't wait to flip the switch on the wasm builds :)

~~~
titzer
Do you also test with V8?

BTW We're happy that we got some of your demos into the build-suite, but
unfortunately we can't run them anymore. The binaries there are still version
0xA and the .wast files have some errors that prevent translating them to 0xB
with the sexpr-wasm tool.

~~~
flohofwoe
I haven't tested with V8 yet (only the final result in Chrome Canary). I'm
happy to (try at least) provide a PR with fresh builds :)

------
z3t4
I don't think it answered why ... If you need better performance, you should
go closer to the metal anyway?

Isn't the purpose of JS that you would easily be able to view the source, that
it's actually source code running, and not binary!?

~~~
TazeTSchnitzel
JS was meant to be a simple scripting language for web pages. But now that we
have huge applications we're compiling from C or C++, plaintext isn't the best
format.

Binary formats are nothing new to the web, it's used them for images and such
for a long time now. In fact, the one raster plaintext image format (XBM) is
no longer supported.

~~~
z3t4
The attack vector of a image format is minuscule compared to actual running
code. It's not like you are worrying about a jpg image performing an x-site
injection.

SVG's are quite popular!

~~~
TazeTSchnitzel
Font and image binary format parsing have been the source of plenty of zero-
days over the years. :)

------
psycolin
any way to get the video of this talk?

~~~
ltratt
We're working on it. Keep an eye on [http://soft-
dev.org/events/vmss16/](http://soft-dev.org/events/vmss16/) over the coming
days.

------
brighteyes
> V8 was the first really fast JavaScript Virtual Machine

This is just barely technically correct, at best.

Chrome launched its first pre-release version on Sep 8 2008 [1], while
WebKit's SFX JIT showed up in pre-release versions of WebKit just 10 days
later [2] (or less, 10 days is when the blogpost came out).

Also, Firefox's TraceMonkey JIT landed on trunk Aug 8 2008 [3] which is before
Chrome's pre-release (however, it was not yet turned on by default in
nightlies at that time).

V8 is a wonderful VM and Google should be proud of it, but the PR line of "V8
was the first really fast JS VM" is debatable. Something like "one of the
first really fast JS VMs" would be more honest.

[1]
[https://en.wikipedia.org/wiki/Google_Chrome](https://en.wikipedia.org/wiki/Google_Chrome)

[2] [https://webkit.org/blog/214/introducing-squirrelfish-
extreme...](https://webkit.org/blog/214/introducing-squirrelfish-extreme/)

[3] [http://arstechnica.com/information-
technology/2008/08/firefo...](http://arstechnica.com/information-
technology/2008/08/firefox-to-get-massive-javascript-performance-boost/)

~~~
icefox
I must say it was a fantastic time to watch the web evolving over those
months. As every browser over a short period of time but IE produced
JavaScript engines that were not just slightly faster, but radically faster
websites adapted and there was within months sites would load in seconds
everyone but on IE where it would be minutes. It introduced a binary
incompatibility of sorts on the web and users were now abandoning IE because
the sites they wanted to use were too slow to be useful.

To a lesser degree we are starting to see a similar post of article starting
with Opera, Safari, and IE working on reducing their energy usage while oddly
it is Chrome that is silent. Just like before a product with a significantly
superior feature has caused me to switched. But this time it was back to
Safari from Chrome. But the Chrome team is not asleep at the wheel like the
Microsoft was and I am expecting/hoping within a year or two there to be a
post with dramatic energy savings made by the Chrome team.

~~~
gavinpc
Yes, well if they are really running an _eye tracker_ with your webcam to time
GC pauses, then it's a case of robbing Peter to pay Paul.

But umm... they don't really do that, right?

~~~
rictic
I think that was tongue in cheek. There are related ideas though, like doing
aggressive GC of tabs which are invisible. Browsers are doing better and
better jobs of prioritizing work based on how it will affect user perceptions
of performance.

