For example, there are embedded users of wasm whose devices don’t even have MMUs. And even when running on a device with an MMU, the host may not want to allow arbitrary mappings, e.g. if using wasm as a plugin system in a database or something.
It’s likely imo that any “fully virtual” features will be part of the wasm web API and not the core spec, if they happen at all.
https://community.arm.com/arm-community-blogs/b/architecture...
https://stackoverflow.com/questions/50966676/why-do-arm-chip...
> If WebAssembly gets popular enough there will probably be hardware acceleration for it.
ARM already tried that back in the days with Jazelle. Plus much of the point of WASM is that you can compile it to machine code during loading.
Often it is just a tiny loop that one wants to optimize. Writing it manually in WAT would be nice. But adding a whole toolchain and a compile step to the stack is not worth it.
Shouldn't it be straight forward to compile WAT to WASM? I hope one day browsers will support it.
Having a proper and well defined ISA is a lot more compelling.
Not only that, but it allows WASM-only compilers and runtimes with none of the JS baggage, and thus use of WASM outside of a browser context and with significantly lower resources requirements.
If speed is fine, why would a user care if the application was compiled to a language with "half-assed semantics" in a text format?
If speed is fine, why would I care if a compiler compiled to a human-friendly language?
From a performance perspective it's also a different target for web engines so has different opportunities for optimization. It's not clear to me we've reached the limit on that at the moment, or how much work browser developers are putting in to optimizing their WASM codepaths. The standard also includes support for things like SIMD which is not natively available in JS land which should provice a boost for suitable workloads and there is a lot coming through the proposal pipeline (https://github.com/WebAssembly/proposals) that will also let WASM diverge more from JS.
From a developer perspective allowing more languages than JS also has some productivity benefits. Both in using languages they are more familiar with and those better suited to certain domains. For example you can write math code in JS, in particular making use of TypedArrays to help things along but its much more straightforward in a language that supports more 'native' types.
Regarding runtime performance, you said "Javascript isn't drastically slower than WASM in most situations."
So are you saying that the reason WASM exists is to have faster compile times than asm.js, or marginally faster runtime perf in most situations, or drastically faster runtime perf in rare situations?
- Both WASM and asm.js don't incur JS garbage collector overhead, but it's also possible to write (mostly) garbage-free Javascript by hand.
- Both WASM and asm.js don't use Javascript objects or strings (only numbers), and especially not JS objects where the interior structure changes randomly - which in turn might cause JIT recompiles, but it's also possible to write such 'static' Javascript by hand, especially when using Typescript.
That's basically about the claim 'Javascript performance can be close to WASM'. It's possible to write JS manually which is 'optimization-friendly', but is not necessarily idiomatic JS - the extreme version of this optimization-friendly JS is asm.js, but nobody would want to write that by hand.
Then of course WASM pushes the optimization wall a bit further then what's possible with JS, which may increase the performance gap in very specific situations:
- WASM has native 64-bit integers (JS has BigInt now, but I don't know if they optimize as well under the hood)
- modern WASM has SIMD instructions, which was once an ECMAScript proposal, but has been abandondend in favour of WASM SIMD: https://github.com/tc39/ecmascript_simd
Finally there's the historical angle (e.g. "why does WASM exist in the first place"):
TL;DR:
- with the end of native plugins, Java and Flash in the browser, people were looking for new alternatives to Javascript in the browser
- around 2008(?) Emscripten demonstrated that compiling C/C++ to a subset of Javascript can give surprisingly good performance
- this subset was then formalized into asm.js and browsers started to add specific optimizations for that subset (via "use asm")
- but this JS subset was a dead-end in the long run because requirements for a "Javascript-as-compile-target" clashed more and more with "Javascript-as-programming-language"
- ...so a split was made and WASM was created, from now on, Javascript could focus again to be a programming language, and WASM could focus on being a compile target
I guess that's it...
Furthermore, JS semantics are limiting in other respects. E.g. there are people looking at tail calls and continuations in WebAssembly, which I can't see ever coming to JS.
This was basically what the special asm.js support in JS engines was about (via "use asm") and brought performance to about WASM level. IIRC this special asm.js support brought a 2x to 3x performance advantage (e.g. running asm.js in Chrome/Firefox which both had special asm.js support vs Safari which didn't).
AFAIK the initial WASM implementation in browsers was more or less an evolution of that asm.js special-path.
What I mean is that I would like something like this to work:
code = `(
func $add (param $a i32) (param $b i32) (result i32)
local.get $a
local.get $b
i32.add
)`;
module = WebAssembly.compile(code);
alert(module.add(3, 5)); // alerts "8". let wast = require("./wast.js");
let binary = wast.WebAssemblyText.encode("(module)");
Does reserve mean it has exclusive access to? Because it can't possibly be that every single wasm module takes 4GB!
...also WASM is starting to become popular outside the browser where requirements might be very different from running stuff in webpages.
Now possible with this as well as even more capable closed-source untrusted binary blobs with DRM running amock on your machine.
Mozilla (a member part of the W3C) and was supposed to stop such DRM-like software from reaching the web. They have proven to be powerless to allow such software like this to be approved as a web standard.
The ones cheering WASM are the ones who absolutely love DRM and malware blobs in your machine now accessible in the browser.
This is a massive failure of the so-called "Open Web".
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).
Or are you just using a different definition of "DRM" to the rest of us, where your definition is "binary format == DRM"?
FWIW I know plenty of people who are excited about WASM because it + WebGPU/WebGL allows them to put their (sometimes open source) games on a website. "The ones cheering WASM are people who push DRM" is patently and obviously false.
(2) you can't do anything in WASM that you can't also do in JS (and the performance difference is hardly noticeable either for well-optimized JS)