4 ms·

Multiple things are happening in parallel here. On Emscripten's side, we're going to add a feature which translates Emscripten's asm.js output into WebAssembly,

by sunfish 11y ago

Multiple things are happening in parallel here. On Emscripten's side, we're going to add a feature which translates Emscripten's asm.js output into WebAssembly, so that existing Emscripten users can easily use WebAssembly. This will indeed be a fairly simple step. [0] The new WebAssembly backend is being developed in upstream LLVM from the beginning, and will be targetting WebAssembly directly rather than going through asm.js, so it will eventually have several advantages. And when it's ready, Emscripten itself will make use of it (though that won't be the only way it can be used) [1]. [0] https://github.com/WebAssembly/design/blob/master/FAQ.md#whats-the-story-for-emscripten-users https://github.com/WebAssembly/design/blob/master/FAQ.md#wha... [1] https://github.com/WebAssembly/design/blob/master/FAQ.md#what-compilers-can-i-use-to-build-webassembly-programs https://github.com/WebAssembly/design/blob/master/FAQ.md#wha...

echeese 11y ago
Are there any examples of the text format of wasm?
- TazeTSchnitzel 11y ago
  It doesn't yet exist. The specifications haven't been written, these are high-level design documents.
  - kayamon 11y ago
    Based on the spec so far, there's a very good chance it'll look _almost exactly like asm.js_
    - TazeTSchnitzel 11y ago
      Yes. Like asm.js it will more closely resemble C than assembly language, having expressions and variables.
cpeterso 11y ago
Will there be any advantage to generating asm.js over WebAssembly+polyfill for clients that don't support WebAssembly natively?
- TazeTSchnitzel 11y ago
  The polyfill is slower.
  - magicalist 11y ago
    It really depends on what you mean by "slower". Emscripten already supports the "Emterpreter"[1], which uses a straight bytecode (not AST, like webassembly) version of your asm.js code that can be downloaded and parsed quickly while the much more verbose asm.js code is still downloading and being parsed. So while it does more work, it's responsive sooner. If fast start up time is the top priority for your app, the polyfill could easily be the best choice (and there are probably more tricks to be done with incremental parsing by feeding the JS engine wasm -> asm.js code in chunks while running an interpreter in the meantime, prioritizing hot functions in the wasm stream). [1] https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/ https://blog.mozilla.org/research/2015/02/23/the-emterpreter...
  - sunfish 11y ago
    The polyfill generates essentially the same asm.js code, so it runs at a similar speed. The slowdown is a translation delay at startup. On the other hand, WebAssembly code is smaller than asm.js code, so it downloads faster, so in some situations the polyfill is actually faster.

by sunfish 11y ago

echeese 11y ago

Are there any examples of the text format of wasm?

TazeTSchnitzel 11y ago
It doesn't yet exist. The specifications haven't been written, these are high-level design documents.
- kayamon 11y ago
  Based on the spec so far, there's a very good chance it'll look _almost exactly like asm.js_
  - TazeTSchnitzel 11y ago
    Yes. Like asm.js it will more closely resemble C than assembly language, having expressions and variables.

cpeterso 11y ago

Will there be any advantage to generating asm.js over WebAssembly+polyfill for clients that don't support WebAssembly natively?

TazeTSchnitzel 11y ago
The polyfill is slower.
- magicalist 11y ago
  It really depends on what you mean by "slower". Emscripten already supports the "Emterpreter"[1], which uses a straight bytecode (not AST, like webassembly) version of your asm.js code that can be downloaded and parsed quickly while the much more verbose asm.js code is still downloading and being parsed. So while it does more work, it's responsive sooner. If fast start up time is the top priority for your app, the polyfill could easily be the best choice (and there are probably more tricks to be done with incremental parsing by feeding the JS engine wasm -> asm.js code in chunks while running an interpreter in the meantime, prioritizing hot functions in the wasm stream). [1] https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/ https://blog.mozilla.org/research/2015/02/23/the-emterpreter...
- sunfish 11y ago
  The polyfill generates essentially the same asm.js code, so it runs at a similar speed. The slowdown is a translation delay at startup. On the other hand, WebAssembly code is smaller than asm.js code, so it downloads faster, so in some situations the polyfill is actually faster.