6 ms·

Is WebAssembly Memory64 worth using?

39 points by bvisness 2y ago

delifue 2y ago
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/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/arm-community-blogs/b/architecture... https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip...
- mort96 2y ago
  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 2y ago
  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.
mwkaufma 2y ago
Love to visit untrusted websites that feel entitled to over 4gb ram without asking.
- saagarjha 2y ago
  4 GB VA space. Page tables aren’t that expensive.
  - mwkaufma 2y ago
    The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
    - saagarjha 2y ago
      On the flip side, it would do you well to read this: https://news.ycombinator.com/newsguidelines.html 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.
      - mwkaufma 2y ago
        Yeah, I hate that JS can do it too. Website bloat is a problem we should be fixing, not accepting. Have you tried to browse the web on a "budget laptop" lately?
        saagarjha 2y ago
        I don't think "here is technology to let websites address more RAM" is the cause of web bloat.
  - mort96 2y ago
    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 2y ago
      The website may want to, but I don't.
    - 2y ago
- flohofwoe 2y ago
  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 2y ago
    [flagged]
TekMol 2y ago
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.
- pjmlp 2y ago
  You can do that easily with binaryen already, and make use of parseText(). https://web.dev/articles/binaryen https://web.dev/articles/binaryen
  - TekMol 2y ago
    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 2y ago
      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)"); [0] https://github.com/WebAssembly/spec/tree/main/interpreter#javascript-library https://github.com/WebAssembly/spec/tree/main/interpreter#ja...
    - pjmlp 2y ago
      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.
- deleted 2y ago
  [deleted]
- flohofwoe 2y ago
rvz 2y ago
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".
- flohofwoe 2y ago
  (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)
- mort96 2y ago
  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.
- jandem 2y ago
  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).
InkCanon 2y ago
"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!
- josephcsible 2y ago
  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.
- flohofwoe 2y ago
  It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.
flohofwoe 2y ago
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.
yuri91 2y ago
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.
- bvisness 2y ago
  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.

39 points by bvisness 2y ago

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/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions https://community.arm.com/arm-community-blogs/b/architecture... https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip...

mort96 2y ago
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 2y ago
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.

mwkaufma 2y ago

Love to visit untrusted websites that feel entitled to over 4gb ram without asking.

saagarjha 2y ago
4 GB VA space. Page tables aren’t that expensive.
- mwkaufma 2y ago
  The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
  - saagarjha 2y ago
    On the flip side, it would do you well to read this: https://news.ycombinator.com/newsguidelines.html 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.
    - mwkaufma 2y ago
      Yeah, I hate that JS can do it too. Website bloat is a problem we should be fixing, not accepting. Have you tried to browse the web on a "budget laptop" lately?
      - saagarjha 2y ago
        I don't think "here is technology to let websites address more RAM" is the cause of web bloat.
- mort96 2y ago
  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 2y ago
    The website may want to, but I don't.
  - 2y ago
flohofwoe 2y ago
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 2y ago
  [flagged]

TekMol 2y ago

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.

pjmlp 2y ago
You can do that easily with binaryen already, and make use of parseText(). https://web.dev/articles/binaryen https://web.dev/articles/binaryen
- TekMol 2y ago
  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 2y ago
    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)"); [0] https://github.com/WebAssembly/spec/tree/main/interpreter#javascript-library https://github.com/WebAssembly/spec/tree/main/interpreter#ja...
  - pjmlp 2y ago
    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.
deleted 2y ago
[deleted]
flohofwoe 2y ago

rvz 2y ago

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".

flohofwoe 2y ago
(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)
mort96 2y ago
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.
jandem 2y ago
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).

InkCanon 2y ago

"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!

josephcsible 2y ago
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.
flohofwoe 2y ago
It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.

flohofwoe 2y ago

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.

yuri91 2y ago

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.

bvisness 2y ago
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.