4 ms·
Tail calls are super important for non-C like control flow, and it's great that it might be added. But what I really think wasm should focus on is to get near
by continuational 4y ago
Tail calls are super important for non-C like control flow, and it's great that it might be added.
But what I really think wasm should focus on is to get near native performance (say, <50% overhead). Until that happens, the whole endeavor seems pointless to me.
- azakai 4y agoEstimates vary (because benchmarks and use cases vary), but it's generally faster than 50%. That number was seen here, https://www.usenix.org/system/files/atc19-jangda.pdf https://www.usenix.org/system/files/atc19-jangda.pdf (I assume that's what you refer to?) It's a good measurement, but it's from 2019, and it's just on 2 wasm engines. There are other estimates, like here: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html That tries to measure the fundamental overhead of wasm's sandboxing as opposed to a specific wasm VM, and it finds just 14%.
- continuational 4y agoThat seems very promising. If it really is that good, wasm has a lot more potential in my eyes. But e.g. sharp/vips ended up with a much worse result: https://www.libvips.org/2020/09/01/libvips-for-webassembly.html https://www.libvips.org/2020/09/01/libvips-for-webassembly.h... It may just be a matter of waiting for simd and threads though.