Firefox’s new streaming and tiering compiler
hacks.mozilla.org
Firefox’s new streaming and tiering compiler
1–10 of 229 posts
Re: Firefox’s new streaming and tiering compiler
#2Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine.
As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it
Re: Firefox’s new streaming and tiering compiler
#3https://lukewagner.github.io/test-tanks-compile-time/
Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s)
Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s)
Wow.
(Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)
Re: Firefox’s new streaming and tiering compiler
#4Caching of compiled code! As i read it they want to cache the wasm bytecode at the client level. What if servers did the caching instead? Group clients by the architectures they use and serve the cached bytecode to the right 'groups' of clients.
Re: Firefox’s new streaming and tiering compiler
#5Nice article.
Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!"
Re: Firefox’s new streaming and tiering compiler
#6Caching of compiled code! As i read it they want to cache the wasm bytecode at the client level. What if servers did the caching instead? Group clients by the architectures they use and serve the cached bytecode to the right 'groups' of clients.
That would assume you trust the server not to give you malicious machine code (which you of course cannot!). wasm is specified in such a way that it is still sandboxed by the VM that compiles it. If you fetch arbitrary machine code, you cannot verify it and that leads to huge security holes!
Re: Firefox’s new streaming and tiering compiler
#7Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…
Yeah I read the article too and thought: but what can I do with wasm?
Re: Firefox’s new streaming and tiering compiler
#8Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…
> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!"
Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.
Re: Firefox’s new streaming and tiering compiler
#9Caching of compiled code! As i read it they want to cache the wasm bytecode at the client level. What if servers did the caching instead? Group clients by the architectures they use and serve the cached bytecode to the right 'groups' of clients.
Compiling wasm also enforces security rules. Offloading that would require full trust of the server, which is probably not desirable.
Re: Firefox’s new streaming and tiering compiler
#10Out of curiosity, using just released versions of browsers on this 2015 mac pro:
Firefox 57: WebAssembly.instantiate took 2990.2ms (4.1mb/s) Chrome 63: WebAssembly.instantiate took 8736.9ms (1.4mb/s) Safari 11.0.2: WebAssembly.instantiate took 10341ms (1.2mb/s)
If more speed is about to arrive, wow.
I'm curious what optimisations are needed / valuable for wasm files to improve streaming performance. I'm assuming if, e.g.:
def foo(baz): bar(baz)
...
def bar(baz): baz = baz +1
Then compilation would start and get stuck until it had a definition for bar? If so, presumably the next build time optimisations for a website will be to shuffle the code around in to as optimal an order as possible so as to improve streaming compilation speed?