4 ms·

You could actually exec wasm with a JS/asm polyfill

by themihai 9y ago

Filligree 9y ago
You want to run a bytecode interpreter in JS? What's battery life going to look like with that?
- themihai 9y ago
  That should encourage the browser vendors to support wasm natively, right?
  - dbbk 9y ago
    They do? This article is about browser vendors supporting wasm.
    - themihai 9y ago
      >> This article is about browser vendors supporting wasm. And my comment was about old browsers/OSes not supporting wasm.
      - dbbk 9y ago
        The reason old browsers don't support WASM is because they can't go back in time... the modern versions do (for instance Edge).
vanderZwan 9y ago
I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming. I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback: One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant. Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor. Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js... I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway. [0] https://jsperf.com/function-vs-constructor-vs-eval/7 https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor https://jsperf.com/function-by-constructor
- themihai 9y ago
  well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 )
  - vanderZwan 9y ago
    Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.

You could actually exec wasm with a JS/asm polyfill

Filligree 9y ago

You want to run a bytecode interpreter in JS? What's battery life going to look like with that?

themihai 9y ago
That should encourage the browser vendors to support wasm natively, right?
- dbbk 9y ago
  They do? This article is about browser vendors supporting wasm.
  - themihai 9y ago
    >> This article is about browser vendors supporting wasm. And my comment was about old browsers/OSes not supporting wasm.
    - dbbk 9y ago
      The reason old browsers don't support WASM is because they can't go back in time... the modern versions do (for instance Edge).

vanderZwan 9y ago

I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming. I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback: One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant. Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor. Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js... I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway. [0] https://jsperf.com/function-vs-constructor-vs-eval/7 https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor https://jsperf.com/function-by-constructor

themihai 9y ago
well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 https://github.com/lukewagner/polyfill-prototype-1 )
- vanderZwan 9y ago
  Of course, but I'm basically asking which of the two possible fallbacks would be better: - test for presence of WASM, if absent fetch the pre-compiled asm.js fallback - test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js. There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times. The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy: 1. On the main thread, the client kicks off a load of a URL by calling loadWebAssembly and receives a Promise<Function>. 2. The polyfill library starts up a worker containing asm.js code compiled from unpack.cpp concatenated with the glue code in load-wasm-worker.js. 3. The worker glue code fetches the binary via XHR then copies the result into the asm.js heap. 4. The asm.js code decodes the binary into asm.js in the form of UTF8 bytes in a separate region of the asm.js heap. 5. The worker glue code creates a Blob (a read-only copy) from a view of just the asm.js UTF8 bytes. 6. The Blob is postMessage()ed back to the main thread (a non-copying operation) where it is loaded as a script element with script.src = URL.getObjectURL(blob). 7. When the asm.js script is executed, it passes the asm.js module function object to a callback which resolves the promise in step 1.