Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox’s new streaming and tiering compiler

hacks.mozilla.org

Post reply on HN
Print view View original

81–90 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#81

Post by ehsankia »

luke_wagner wrote: post #76
axelfontaine wrote: post #49

Using https://lukewagner.github.io/test-tanks-compile-time/ Chrome 63: 3143.7ms (3.9mb/s) Firefox 57: 1499ms (8.3mb/s) Edge 41: 97.3ms (127.2mb/s) !!!

To wit, as described in their blog post: https://blogs.windows.com/msedgedev/2017/04/20/improved- Edge validates and compiles wasm code lazily. Thus, this simplistic benchmark isn't really measuring compile time on Edge. In contrast, Firefox, Chrome and Safari are doing some amount of AOT compilation before WebAssembly.instantiate() resolves.

Here's a stupid question, but is the result of the Firefox and Chrome "instantiate" the exact same? Is the compilation doing the same job, or one could be performing more optimizations? Aka faster compilation but slower execution.

Re: Firefox’s new streaming and tiering compiler

#82

Post by dfox »

filereaper wrote: post #74

Total Aside. As a compiler and runtimes guy, I'm super excited for streaming compilation. I think stuff like this and ethereum for distributed computation is really cool stuff! :D

Streaming compilation is the way it was always historically done. One reason is that computers used to not have enough RAM to store whole non-trivial programs in it in AST or another intermediate form.

Second reason is that this approach matches how the underlying theory of languages and automatons works. One can view modern AST producing compiler frontend as compiler that compiles it's input into program that builds the resulting AST.

On the other hand many modern optimalization passes simply cannot be done in streaming manner or even by any pushdown automaton.

Re: Firefox’s new streaming and tiering compiler

#83

Post by hateduser2 »

sjrd wrote: post #14
icen wrote: post #8

Earlier quoted context omitted.

> 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.

I can't tell whether you're being sarcastic or not, so I will answer as if you are not. Yes, it is absurd. Because your wasm that was compiled from JS needs to embed an entire implementation of the dynamic nature of JS. And to make all those dynamic features remotely fast, you cannot just compile them as is. You need to use a JIT to be able to perform speculative optimizations. But then, where's the JIT? Oh, it's bui…

They’re adding gc and dom support to wasm

Re: Firefox’s new streaming and tiering compiler

#84

Post by hateduser2 »

sjrd wrote: post #6
stevemk14ebr wrote: post #4

Caching 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!

Why can’t you just cache it with a hash?

Re: Firefox’s new streaming and tiering compiler

#85

Post by dfox »

avaer wrote: post #68
flavio81 wrote: post #51

Earlier quoted context omitted.

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.

Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.

Re: Firefox’s new streaming and tiering compiler

#86

Post by icebraining »

hateduser2 wrote: post #84
sjrd wrote: post #6

Earlier quoted context omitted.

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!

Why can’t you just cache it with a hash?

How would the client know the hash is valid?

Re: Firefox’s new streaming and tiering compiler

#87

Post by dragonwriter »

flavio81 wrote: post #51
sjrd wrote: post #5

Nice 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…

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

Declarative UI systems that look a lot like HTML+CSS+JS, keep cropping up in other domains besides the web; I think, but for increasing freedom to replace the JS part with some other languages to specify behavior, the basic model will be around for a long time.

Re: Firefox’s new streaming and tiering compiler

#88

Post by dragonwriter »

avaer wrote: post #68
flavio81 wrote: post #51

Earlier quoted context omitted.

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.

Or something like X3dom will take center stage.

Re: Firefox’s new streaming and tiering compiler

#89

Post by icebraining »

jnordwick wrote: post #44

I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference? Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.

Why Hotspot? There are many bytecode languages, with their own execution environments - .NET/CLR, Parrot, BEAM, etc. wasm is an attempt to design one specifically for the web, rather than trying to shoehorn one made for a different environment.

Re: Firefox’s new streaming and tiering compiler

#90

Post by dfox »

pjmlp wrote: post #71
cwzwarich wrote: post #45

Earlier quoted context omitted.

> Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Intel i432 was far from the last attempt. Besides all of the Lisp HW developed after it, Azul made CPUs in the 2000s with hardware support for GC. Acceleration of concurrent copying collection requires a surprisingly low amount of CPU support.

I had my history reversed regarding i432 vs Lisp HW. You are right I also forgot about Azul, but eventually they dropped it, because it wasn't worthwhile anymore, just like it happened with all other specialized hardware implementations.

Azul (and AFAIK most lisp machines) does not do garbage collection in hardware. In these contexts the "GC HW" involves hardware acceleration of read/write barriers required by concurrent and incremental GCs (which otherwise requires the compiler/JIT to inline implementation of barriers into user code). The reason why Azul can now use stock amd64 CPUs is that they found that you can abuse the MMU to provide exactly this kind of HW accelerated barriers.
Post reply on HN