Looking forward to progress on the memory control proposal(s).
Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.
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.
ARM already have a special instruction `FJCVTZS` to accelerate JavaScript. If WebAssembly gets popular enough there will probably be hardware acceleration for it.
JavaScript is in the name, but really it's just a way to convert floats to ints with the kind of rounding that x86 does. The impetus might've been to run JS faster because JS specifies x86 semantics, but it's not like it's some wild "JavaScript acceleration instruction". I don't really get why they put JavaScript in the name to be honest.
Except FJCVTZS is not exclusively useful to javascript. Its behaviour is that of x86 rounding, which is what the JS spec encodes. So it’s also useful for x86 emulation / compatibility in general.
> 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.
The reason I don't use WebAssembly is that browsers do not support the text format.
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.
You could use handwritten asmjs in that case. I did it at work to improve performance on some pixel-wise software rendering we were doing. (We have since then switched to WebGL, but asmjs was a nice stepping stone.) If I recall correctly, it basically boils down to using small fixed size arrays and appending "|0" after each uint32 operation and "+" in front of each float32 operation - so it's something you can do by hand. Of course, one of my colleagues then made a tweak which gave a surprisingly huge slowdown - you should probably declare loudly (with comments etc.) that a certain code block is intended to be asmjs if you do this in a large codebase.
asmjs is great. Imho the better approach than wasm. But it seems to not have great browser support (no Safari for example). And support is probably not getting better in the future.
Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower than WASM in most situations.
Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?
Unless you want to install a crypto miner to run locally on someone's machine when they visit a website.
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".
Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
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).
DRM? That's news to me, the only DRM I was aware of in the web was EME. Can you elaborate?
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.
It's really reserving 4GB of the process's own address space, but the only part of it that physical memory has to get used for is the part that actually has stuff stored in it.
That's virtual address space, not physical RAM. E.g. (if my math is correct) 0.0015 percent of the available space per WASM process. I think that's acceptable ;)
TL;DR: no, unless you actually need more than 32-bit address range. The other advantages of 64-bit CPUs (e.g. 64-bit integer registers, more general purpose registers) are already taken advantage of by wasm32.
Looking forward to progress on the memory control proposal(s). Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.
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.
ARM already have a special instruction `FJCVTZS` to accelerate JavaScript. If WebAssembly gets popular enough there will probably be hardware acceleration for it.
https://community.arm.com/arm-community-blogs/b/architecture...
https://stackoverflow.com/questions/50966676/why-do-arm-chip...
JavaScript is in the name, but really it's just a way to convert floats to ints with the kind of rounding that x86 does. The impetus might've been to run JS faster because JS specifies x86 semantics, but it's not like it's some wild "JavaScript acceleration instruction". I don't really get why they put JavaScript in the name to be honest.
Except FJCVTZS is not exclusively useful to javascript. Its behaviour is that of x86 rounding, which is what the JS spec encodes. So it’s also useful for x86 emulation / compatibility in general.
> 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.
The reason I don't use WebAssembly is that browsers do not support the text format.
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.
You could use handwritten asmjs in that case. I did it at work to improve performance on some pixel-wise software rendering we were doing. (We have since then switched to WebGL, but asmjs was a nice stepping stone.) If I recall correctly, it basically boils down to using small fixed size arrays and appending "|0" after each uint32 operation and "+" in front of each float32 operation - so it's something you can do by hand. Of course, one of my colleagues then made a tweak which gave a surprisingly huge slowdown - you should probably declare loudly (with comments etc.) that a certain code block is intended to be asmjs if you do this in a large codebase.
asmjs is great. Imho the better approach than wasm. But it seems to not have great browser support (no Safari for example). And support is probably not getting better in the future.
Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower than WASM in most situations.
Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?
17 replies →
You can do that easily with binaryen already, and make use of parseText().
https://web.dev/articles/binaryen
Not sure what you mean. I guess this is a misunderstanding.
What I mean is that I would like something like this to work:
2 replies →
Unless you want to install a crypto miner to run locally on someone's machine when they visit a website.
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".
Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
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).
DRM? That's news to me, the only DRM I was aware of in the web was EME. Can you elaborate?
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.
(1) WASM can be blocked with regular ad-blockers (just like JS)
(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)
"How do browsers take advantage of this fact? By reserving 4GB of memory for every single WebAssembly module."
Does reserve mean it has exclusive access to? Because it can't possibly be that every single wasm module takes 4GB!
It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.
It's really reserving 4GB of the process's own address space, but the only part of it that physical memory has to get used for is the part that actually has stuff stored in it.
Love to visit untrusted websites that feel entitled to over 4gb ram without asking.
That's virtual address space, not physical RAM. E.g. (if my math is correct) 0.0015 percent of the available space per WASM process. I think that's acceptable ;)
[flagged]
4 GB VA space. Page tables aren’t that expensive.
Isn't the whole reason they're adding 64 bit addresses to support websites which want to use over 4GiB? What other reason could there be?
5 replies →
The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
2 replies →
TL;DR: no, unless you actually need more than 32-bit address range. The other advantages of 64-bit CPUs (e.g. 64-bit integer registers, more general purpose registers) are already taken advantage of by wasm32.