There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.
There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it.
Saying goodbye to asm.js
11–20 of 164 posts
Re: Saying goodbye to asm.js
#12I’ll never forget watching Gary Bernhardt give his talk on JavaScript.[0] Was my introduction to asm.js, and the rabbithole associated with compiling code to run in the browser.
12 years on, it’s shocking how much of his fiction became reality.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Re: Saying goodbye to asm.js
#13There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.
There are some WAT compilers that are small and fast for running in the browser.
Re: Saying goodbye to asm.js
#14There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.
It will still work. asm.js is just regular JavaScript code, after all. It just won't parse/run as fast as custom pipeline for asm.js. My guess is that you will not notice much difference unless you have a really huge application.
Re: Saying goodbye to asm.js
#15So the death of asm.js is upon us?
We are drifting away from the timeline of the prophecy:
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)
Re: Saying goodbye to asm.js
#16Earlier quoted context omitted.
can we see?
yeah check back at the end of the day. will try to rip it out of the project and put it in a standalone benchmark.
It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256
Re: Saying goodbye to asm.js
#17Asm.js was never needed as a legacy mechanism, as it was just a compilation target for native code. There was nothing that it needed to remain backwards compatible with, all asm.js code was new code.
Re: Saying goodbye to asm.js
#18Asm.js is dead! Long live WebAssembly!
[deleted]
Re: Saying goodbye to asm.js
#19I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK.
But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead.
But I wasn't sure that emscripten still fully supported it.
You can't call most web apis from wasm.
But more important for what i was trying to do, you can't zero copy buffers from js to wasm.
Everything is a trade off. The isolation is a good thing, but also a bad thing.
Re: Saying goodbye to asm.js
#20Earlier quoted context omitted.
yeah check back at the end of the day. will try to rip it out of the project and put it in a standalone benchmark.
It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256
Noted, will add that.
Last time I tried https://github.com/Daninet/hash-wasm
edit: I focus on browsers, that's wasm but not for browser envs.
----
https://theultdev.github.io/web-sha256-benchmark
https://github.com/TheUltDev/web-sha256-benchmark
seems it is chrome wasm that is slow.
asmjs is about the same speed in chrome and firefox (with asm optimizations still enabled) but wasm is slow as hell in chrome, asm still better.
side note: someone mentioned native crypto.subtle, but that doesn't have incremental hashing so can't use it for large files. however I do use it in practice for smaller files.