luke_wagner

To the question of "how would dynamic linking work in the future", as already stated in the article, a nanoprocess doesn't need to correspond 1:1 to a wasm module/instance. Rather, N wasm instances can share a single wasm memory to collectively represent a single nanoprocess. From an external point of view, whether a nanoprocess is implemented as 1 or N instances wouldn't be visible -- it's an impl detail -- and the memory is (still) encapsulated by the nanoprocess. Thus, there is a two-level hierarchy of: a graph of shared-nothing-linked nanoprocesses each containing a graph of shared-everything wasm instances.

There's still a lot more details to figure out, of course, but that's true for wasm dynamic (shared-everything) linking in general.

That's true for the "threading MVP", but there is also discussion about adding "pure wasm threads" as a follow-up which avoids worker overhead/limitations.

That comment (which I made) explains why probably the best we can expect for wasm accessing normal JS objects is the same level of speed as a modern JS engine's "tier 1"/"baseline" JIT. But the Rust code discussed in the OP wasn't accessing JS objects, it was accessing Rust memory which lives in wasm's "linear memory", so I don't see how my comment really disagrees with what jandem or dikaiosune are saying.

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.

Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-...

Maybe some terminology difference here but what I meant by 'pure JIT' was that, iiuc, Chakra waits until the function is called to even validate it, then warms up in an interpreter and only if the function is hot compiles it in a background thread. I think that's one end of the eager/lazy spectrum that may well be what a category of wasm uses will want.

I think the primarily-AOT compilation strategy we see today is a consequence of many of the initial workloads being frame-based animation where AOT avoids animation stutters. But this is likely to evolve over time as wasm workloads evolve. If and when we see wasm showing up in frameworks in contexts where page-load is the primary concern I can see a more lazy JIT strategy being the right thing and then we'd want to specify some sort of developer knob to control this. But given a pure-JIT approach like Chakra is using, wasm should be able to load code byte-for-byte faster than JS.

Related: http://mozillamemes.tumblr.com/post/20381316930/inspired-by-... http://mozillamemes.tumblr.com/post/22247147806/desperate-ti... http://mozillamemes.tumblr.com/post/19721622462/no-matter-ho...