luke_wagner

6 ms·

1.
by luke_wagner 7y ago
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 wa
2.
by luke_wagner 8y ago
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.
3.
by luke_wagner 9y ago
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 discu
4.
by luke_wagner 9y ago
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 measur
5.
by luke_wagner 9y ago
Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-...
6.
by luke_wagner 9y ago
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
7.
by luke_wagner 9y ago
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.
8.
by luke_wagner 10y ago
Related: http://mozillamemes.tumblr.com/post/20381316930/inspired-by-... http://mozillamemes.tumblr.com/post/22247147806/desperate-ti... http://mozillamemes.tumblr.com/po