Is WebAssembly Memory64 worth using?
47 comments
·January 16, 2025TekMol
rav
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.
null
flohofwoe
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.
TekMol
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?
masklinn
Mozilla tried that with asmjs. Turns out javascript has pretty half-assed semantics (notably around integer types), nobody wants to expand it to a useful compilation (asmjs was mostly an optimisation for hand-written code) target, and few want to compile to text, especially javascript.
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.
null
flohofwoe
Simple: Javascript can focus on being a human-friendly programming language, while WASM can focus on being a compile target. If you've been around in the asm.js times, this conflict was a real concern.
sirwhinesalot
We used to have asm.js for that. For various reasons wasm is a replacement for it. JS doesn't even have proper integer types, it is not a good target language.
pjmlp
You can do that easily with binaryen already, and make use of parseText().
TekMol
Not sure what you mean. I guess this is a misunderstanding.
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".tyushk
The WebAssembly reference interpreter [0] has a JS library that lets you do this.
let wast = require("./wast.js");
let binary = wast.WebAssemblyText.encode("(module)");
pjmlp
Which you can get by making use of binaren.js library already, so you won't get any browser vendor love to include the feature into the browsers directly.
delifue
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...
mort96
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.
masklinn
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.
yuri91
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.
InkCanon
"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!
flohofwoe
It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.
josephcsible
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.
mwkaufma
Love to visit untrusted websites that feel entitled to over 4gb ram without asking.
flohofwoe
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 ;)
mwkaufma
The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
saagarjha
4 GB VA space. Page tables aren’t that expensive.
mort96
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?
mwkaufma
The website may want to, but I don't.
flohofwoe
Yes, but think of DCC applications like Figma which might run into the 4 GB restriction with large data sets, not regular websites which run a couple of WebGL demos written in C.
...also WASM is starting to become popular outside the browser where requirements might be very different from running stuff in webpages.
mwkaufma
The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
saagarjha
On the flip side, it would do you well to read this: https://news.ycombinator.com/newsguidelines.html. As for the actual content of your comment, pages already have access to more than 4 GB of RAM. It's actually quite easy to do just from JavaScript.
rvz
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".
jandem
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).
mort96
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.
flohofwoe
(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)
flohofwoe
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.
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.