3 ms·

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup performance issues, that plague WebAssembly. WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them. VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.

nine_k 3y ago
Actual CPU native assembly? It would need to support x86, x64, and aarch64 by now. (And likely RISC-5 in the near future.) The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation. If you badly need native performance, develop a native application %)
- vilunov 3y ago
  Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.
- torginus 3y ago
  Yeah, actual native assembly. I think doing a cross compilation for 2 architectures (x64 and aarch64) is more than doable, even 4, if you want to be thorough. > The point of VMs like WASM is not (specifically) performance though I feel like it is though. There was another thing, called asm.js back then, which was a subset of javascript that was easily translatable to machine code. It was a giant hack, and performed worse than NaCl. I feel like WASM is more of a spiritual successor of that thing. > If you badly need native performance, develop a native application And pass up the ease of distribution/compatibility browsers offer?

nine_k 3y ago

Actual CPU native assembly? It would need to support x86, x64, and aarch64 by now. (And likely RISC-5 in the near future.) The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation. If you badly need native performance, develop a native application %)

vilunov 3y ago
Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.
torginus 3y ago
Yeah, actual native assembly. I think doing a cross compilation for 2 architectures (x64 and aarch64) is more than doable, even 4, if you want to be thorough. > The point of VMs like WASM is not (specifically) performance though I feel like it is though. There was another thing, called asm.js back then, which was a subset of javascript that was easily translatable to machine code. It was a giant hack, and performed worse than NaCl. I feel like WASM is more of a spiritual successor of that thing. > If you badly need native performance, develop a native application And pass up the ease of distribution/compatibility browsers offer?