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

71–80 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#71

Post by pjmlp »

cwzwarich wrote: post #45
pjmlp wrote: post #36

Earlier quoted context omitted.

I don't see lack of GC as limitation, just bring your alongside. Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Interaction with DOM can be achieved with a few imported functions.

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

Re: Firefox’s new streaming and tiering compiler

#72

Post by filereaper »

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.

I'm not sure that JVM allows for streaming code, its centred around class-loading and classes in general. Shipping in fragments of code will require quite an overhaul of that entire architecture. Lambdas and other constructs were added much later via JSR-292 and invokedynamic, streaming stuff in will require quite a bit of shoehorning.

Re: Firefox’s new streaming and tiering compiler

#73

Post by chrisseaton »

zach43 wrote: post #2

Interesting 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

> I did not realize that the WASM needs to be compiled into machine code on the client system

It doesn't need to be. This is a choice they've made. Other implementations of WASM could interpret it they wanted.

The Church-Turing thesis tells us that any program you can compile to machine code can also be interpreted, so it is not possible that any language needs to be compiled into machine code.

Re: Firefox’s new streaming and tiering compiler

#75

Post by isaacaggrey »

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

Could someone explain how Edge is performing so well or any references to what they have done in this regard? Has the Edge team already implemented this streaming and tiering compiler technique?

Re: Firefox’s new streaming and tiering compiler

#76

Post by luke_wagner »

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.

Re: Firefox’s new streaming and tiering compiler

#77

Post by pjmlp »

wlesieutre wrote: post #66
seren wrote: post #30

Earlier quoted context omitted.

Running a native app compiled to wasm into the browser ? So the opposite of running an Electron app?

Calling it now: 1) Write a Windows app 2) Run it in the browser with wasm 3) Stuff that into Electron and distribute to Mac/Linux/Windows Why distribute the electron wrapped wasm on Windows instead of using the real native Windows app? It's more consistent this way! Single codebase! Developer efficiencies!

Start here,

http://www.mono-project.com/news/2018/01/16/mono-static-weba...

Re: Firefox’s new streaming and tiering compiler

#78

Post by chrisseaton »

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!

> which you of course cannot!

Didn't Google's NaCL implement verification of sandboxed machine code?

Re: Firefox’s new streaming and tiering compiler

#79

Post by pjmlp »

filereaper wrote: post #72
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.

I'm not sure that JVM allows for streaming code, its centred around class-loading and classes in general. Shipping in fragments of code will require quite an overhaul of that entire architecture. Lambdas and other constructs were added much later via JSR-292 and invokedynamic, streaming stuff in will require quite a bit of shoehorning.

That is implementation specific and not defined as part of the JVM specification.

I don't know all the JVM implementations out there, but it wouldn't surprise me if there was one with it implemented.

By the way, RMI and Jini worked by streaming code across the network.

Post reply on HN