3 ms·

The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?

by xydone 4mo ago

sestep 4mo ago
It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.
- xydone 4mo ago
  Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
- senfiaj 4mo ago
  Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
  - flohofwoe 4mo ago
    > The bridge will add more latency when there is a transition between JS and wasm. This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
    - deleted 4mo ago
      [deleted]
whizzter 4mo ago
Apple
- koolala 4mo ago
  they limit some good things on purpose just for the sake of ecosystem competition. but with this they are slowly implementing it?
trumpdong 4mo ago
You don't need 4GB and it wastes memory to make pointers twice as big? Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.
- Narishma 4mo ago
  > Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason. I don't think that ever had much, if any, adoption and it looks like it will be removed in the next few releases.
flohofwoe 4mo ago
I already posted the link in another reply, but this is a good overview why wasm32 is usually the better choice over wasm64: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall... TL;DR: wasm64 has slower memory load/store operation because it requires 'software bounds checking', so unless you absolutely need more than 4 GB RAM, wasm32 is the better choice.

The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?

by xydone 4mo ago

The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?

It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.

xydone 4mo ago
Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
senfiaj 4mo ago
Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
- flohofwoe 4mo ago
  > The bridge will add more latency when there is a transition between JS and wasm. This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
  - deleted 4mo ago
    [deleted]

whizzter 4mo ago

Apple

koolala 4mo ago
they limit some good things on purpose just for the sake of ecosystem competition. but with this they are slowly implementing it?

trumpdong 4mo ago

You don't need 4GB and it wastes memory to make pointers twice as big? Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason.

Narishma 4mo ago
> Even Linux supports running 64-bit code in a 32-bit address space ("x32 ABI") for this reason. I don't think that ever had much, if any, adoption and it looks like it will be removed in the next few releases.

flohofwoe 4mo ago

I already posted the link in another reply, but this is a good overview why wasm32 is usually the better choice over wasm64: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall... TL;DR: wasm64 has slower memory load/store operation because it requires 'software bounds checking', so unless you absolutely need more than 4 GB RAM, wasm32 is the better choice.