6 ms·

32GB in single browser window running web assembly... Why would you ever want to go above this? What is your scenario?

by lahcim2000 2y ago

dagmx 2y ago
I agree that wanting to have more than 32bits of addressable space (not 32GB of memory) in a web app seems excessive. However the real win is the ability to use 64 bit types more easily, if for nothing else other than it simplifies making wasm ports of desktop libraries.
- CryZe 2y ago
  > ability to use 64 bit types more easily Those are available on wasm32 just the same.
  - jltsiren 2y ago
    It goes beyond that. Many languages expect that you use types such as size_t or usize for things that are conceptually collection sizes, array offsets, and similar things. In some applications, it's common that the conceptual collection is larger than 2^32 while using relatively little memory. For example, you could have a sparse set of integers or a set of disjoint intervals in a universe of size 2^40. In a 64-bit environment, you can safely mix 64-bit types and idiomatic interfaces using size_t / usize. In a 32-bit environment, most things using those types (including the standard library) become footguns. I work in bioinformatics. A couple of times a year I check if browsers finally support Memory64 by default. They don't, and I conclude that Wasm is still irrelevant to my work. I no longer remember how long I've been doing that. Cross-platform applications running in a browser would be convenient for many purposes, but the technology is not ready for that.
    - flohofwoe 2y ago
      One could argue that size_t should be 64 bits on wasm32 since it's a hybrid 64/32 bit platform (and there's the ptrdiff types too which then would depend on the pointer size), but I guess sizeof(size_t) != sizeof(void*) breaks too much existing code.
- deleted 2y ago
  [deleted]
umvi 2y ago
32-bit memory addressing means you only have 4GB, not 32GB. The company I current work for makes radiotherapy software. Most of our native apps run in clinics under .NET. There are some cases where we want users or employees to be able to access our radiotherapy tooling from a browser. Microsoft has a pretty phenomenal .NET -> WASM compiler. We can compile our .NET DICOM image viewer tooling to WASM, for example, and it is more performant and full-featured than Cornerstone.js (https://www.cornerstonejs.org/ https://www.cornerstonejs.org/). However, medical imagery is memory heavy. We frequently run into the 4GB limit, especially if the CT/MR image uses 32-bit voxels instead of 16-bit voxels. Or if the field of view was resized. Or if we accidentally introduce an extra image copy in memory.
- azakai 2y ago
  A related example is image editing software like Adobe Photoshop on the Web. Large images can require more then 4GB in many cases.
dale_glass 2y ago
You can compile most anything to webassembly. I believe Unreal Engine supports it. So no reason why a big game with fancy graphics and lots of textures couldn't use it.
- deleted 2y ago
  [deleted]
hinkley 2y ago
Some of us are trying to convince the Node team that pointer compression should be on by default. If you need more than 4G per isolate you're probably doing something wrong that you shouldn't be doing in Node. With compression it's not actually 4GB, it's k * 4GB. Java pointer compression promises up to 32GB of heap with 32 bit pointers, for instance.
- felipellrocha 2y ago
  Wait, how does that work?
  - tzot 2y ago
    Think uint64_t buffer[1<<32]; and your “pointers” are indexes to that array: (void*)(buffer+index)
    - deleted 2y ago
      [deleted]
  - PhilipRoman 2y ago
    If some subset of pointers has a guaranteed alignment of 2^N bytes, then the least significant N bits are always zero, and don't need to be stored explicitly (only restored when dereferencing the pointer)
peutetre 2y ago
WebAssembly doesn't only apply to the browser. It will also be used server side and in applications other than browsers.
- eapriv 2y ago
  Why would anyone do that?
  - peutetre 2y ago
    Because they want to run arbitrary code in a sandboxed environment with well defined interfaces.
  - eknkc 2y ago
    I would, if the thing stabilized enough. For example, in a project needed to rely heavily on markdown and needed the exact same markdown renderer on both server and client. That alone made us choose node.js on the server side so that we could use the same markdown module. Today, I'd probably find a rust / c etc markdown renderer and compile it to wasm. Use it on the server and client as it. This is a silly example but wasm being a universal runtime would allow interfacing things a lot easier. Ah also, things like cloudflare workers let you run wasm binaries on their servers. You can write in in any language that can target wasm and you have a universal runtime. Neat.
  - umvi 2y ago
    Sandboxed environment as an alternative to virtual machine or docker container
  - aseipp 2y ago
    You can embed a C/C++ program into arbitrary places using WASM as a runtime, so if you have any C++ program you want to automate, you can "lift and shift" it into WASM and then wrap it in something like TypeScript. This is surprisingly useful. WASM also removes sources of non-determinism, which may enable you to do things like aggressive caching of programs that would normally be slightly non-deterministic (imagine a program that uses a HashMap internally before dumping its output). I use this to run FPGA synthesis and place-and-route tools portably, on all operating systems, with 100% deterministic output: https://yowasp.org/ https://yowasp.org/ memory64 support will be very useful, because many non-trivial designs will use a lot more than 4GiB of RAM.
Dalewyn 2y ago
Look son, the only way we're gonna get anything done is abstracting the abstractions so we can actually get some abstracted code running on the abstracted abstractions. That means we need 128 gallonbytes of abstracted neural silicon to fit all our abstracted abstractions written by our very best abstracted intelligences. In other words: JavaShit ho!
- akira2501 2y ago
  The web took off because cross compiling sucks. Change my mind.
  - fragmede 2y ago
    Then why didn't Java do better? Its tagline was write once, run everywhere. I remember back in the day setting up cross compiling was horrendous though, so I agree, I just don't think it's the only reason. These days all you do is set a flag and rerun "go build", it's stupidly easy, as far as compiling goes. The other two things that come to mind is that on the web users expect things to look different, so the fact that your cross compiled app looked/behaved like ass on at least one platform unless you basically rewrote the front end to conform to each platforms user interface guidelines (aka write once, rewrite everywhere), meant that websites could look more how the company making the website wanted it to look, and less like how Redmond or Cupertino-bases companies wanted it to look. The real killer feature though, imo, was upgrading of software. Customer support is a big expense that ends up sinking developer time, and if you got bug reports and you fixed the problem, you'd keep getting bug reports for that issue and the CS team would have to figure out which version the customer is on, buried three menus deep, before getting them to upgrade. The website, however is basically always running the latest version, so no more wasting everyone's time with an old install on a customer's computer. And they showed up in metrics for management to see.
    - peutetre 2y ago
      Java's done really well. It's in lots of things: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Java compiles to WebAssembly too. Google uses it: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc
alex_suzuki 2y ago
Run an LLM in a browser…? WebNN!
mepian 2y ago
I agree, 640K ought to be enough for anybody.

32GB in single browser window running web assembly... Why would you ever want to go above this? What is your scenario?

I agree that wanting to have more than 32bits of addressable space (not 32GB of memory) in a web app seems excessive. However the real win is the ability to use 64 bit types more easily, if for nothing else other than it simplifies making wasm ports of desktop libraries.

CryZe 2y ago
> ability to use 64 bit types more easily Those are available on wasm32 just the same.
- jltsiren 2y ago
  It goes beyond that. Many languages expect that you use types such as size_t or usize for things that are conceptually collection sizes, array offsets, and similar things. In some applications, it's common that the conceptual collection is larger than 2^32 while using relatively little memory. For example, you could have a sparse set of integers or a set of disjoint intervals in a universe of size 2^40. In a 64-bit environment, you can safely mix 64-bit types and idiomatic interfaces using size_t / usize. In a 32-bit environment, most things using those types (including the standard library) become footguns. I work in bioinformatics. A couple of times a year I check if browsers finally support Memory64 by default. They don't, and I conclude that Wasm is still irrelevant to my work. I no longer remember how long I've been doing that. Cross-platform applications running in a browser would be convenient for many purposes, but the technology is not ready for that.
  - flohofwoe 2y ago
    One could argue that size_t should be 64 bits on wasm32 since it's a hybrid 64/32 bit platform (and there's the ptrdiff types too which then would depend on the pointer size), but I guess sizeof(size_t) != sizeof(void*) breaks too much existing code.
deleted 2y ago
[deleted]

umvi 2y ago

32-bit memory addressing means you only have 4GB, not 32GB. The company I current work for makes radiotherapy software. Most of our native apps run in clinics under .NET. There are some cases where we want users or employees to be able to access our radiotherapy tooling from a browser. Microsoft has a pretty phenomenal .NET -> WASM compiler. We can compile our .NET DICOM image viewer tooling to WASM, for example, and it is more performant and full-featured than Cornerstone.js (https://www.cornerstonejs.org/ https://www.cornerstonejs.org/). However, medical imagery is memory heavy. We frequently run into the 4GB limit, especially if the CT/MR image uses 32-bit voxels instead of 16-bit voxels. Or if the field of view was resized. Or if we accidentally introduce an extra image copy in memory.

azakai 2y ago
A related example is image editing software like Adobe Photoshop on the Web. Large images can require more then 4GB in many cases.

dale_glass 2y ago

You can compile most anything to webassembly. I believe Unreal Engine supports it. So no reason why a big game with fancy graphics and lots of textures couldn't use it.

deleted 2y ago
[deleted]

hinkley 2y ago

Some of us are trying to convince the Node team that pointer compression should be on by default. If you need more than 4G per isolate you're probably doing something wrong that you shouldn't be doing in Node. With compression it's not actually 4GB, it's k * 4GB. Java pointer compression promises up to 32GB of heap with 32 bit pointers, for instance.

felipellrocha 2y ago
Wait, how does that work?
- tzot 2y ago
  Think uint64_t buffer[1<<32]; and your “pointers” are indexes to that array: (void*)(buffer+index)
  - deleted 2y ago
    [deleted]
- PhilipRoman 2y ago
  If some subset of pointers has a guaranteed alignment of 2^N bytes, then the least significant N bits are always zero, and don't need to be stored explicitly (only restored when dereferencing the pointer)

peutetre 2y ago

WebAssembly doesn't only apply to the browser. It will also be used server side and in applications other than browsers.

eapriv 2y ago
Why would anyone do that?
- peutetre 2y ago
  Because they want to run arbitrary code in a sandboxed environment with well defined interfaces.
- eknkc 2y ago
  I would, if the thing stabilized enough. For example, in a project needed to rely heavily on markdown and needed the exact same markdown renderer on both server and client. That alone made us choose node.js on the server side so that we could use the same markdown module. Today, I'd probably find a rust / c etc markdown renderer and compile it to wasm. Use it on the server and client as it. This is a silly example but wasm being a universal runtime would allow interfacing things a lot easier. Ah also, things like cloudflare workers let you run wasm binaries on their servers. You can write in in any language that can target wasm and you have a universal runtime. Neat.
- umvi 2y ago
  Sandboxed environment as an alternative to virtual machine or docker container
- aseipp 2y ago
  You can embed a C/C++ program into arbitrary places using WASM as a runtime, so if you have any C++ program you want to automate, you can "lift and shift" it into WASM and then wrap it in something like TypeScript. This is surprisingly useful. WASM also removes sources of non-determinism, which may enable you to do things like aggressive caching of programs that would normally be slightly non-deterministic (imagine a program that uses a HashMap internally before dumping its output). I use this to run FPGA synthesis and place-and-route tools portably, on all operating systems, with 100% deterministic output: https://yowasp.org/ https://yowasp.org/ memory64 support will be very useful, because many non-trivial designs will use a lot more than 4GiB of RAM.

Dalewyn 2y ago

Look son, the only way we're gonna get anything done is abstracting the abstractions so we can actually get some abstracted code running on the abstracted abstractions. That means we need 128 gallonbytes of abstracted neural silicon to fit all our abstracted abstractions written by our very best abstracted intelligences. In other words: JavaShit ho!

akira2501 2y ago
The web took off because cross compiling sucks. Change my mind.
- fragmede 2y ago
  Then why didn't Java do better? Its tagline was write once, run everywhere. I remember back in the day setting up cross compiling was horrendous though, so I agree, I just don't think it's the only reason. These days all you do is set a flag and rerun "go build", it's stupidly easy, as far as compiling goes. The other two things that come to mind is that on the web users expect things to look different, so the fact that your cross compiled app looked/behaved like ass on at least one platform unless you basically rewrote the front end to conform to each platforms user interface guidelines (aka write once, rewrite everywhere), meant that websites could look more how the company making the website wanted it to look, and less like how Redmond or Cupertino-bases companies wanted it to look. The real killer feature though, imo, was upgrading of software. Customer support is a big expense that ends up sinking developer time, and if you got bug reports and you fixed the problem, you'd keep getting bug reports for that issue and the CS team would have to figure out which version the customer is on, buried three menus deep, before getting them to upgrade. The website, however is basically always running the latest version, so no more wasting everyone's time with an old install on a customer's computer. And they showed up in metrics for management to see.
  - peutetre 2y ago
    Java's done really well. It's in lots of things: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Java compiles to WebAssembly too. Google uses it: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc

alex_suzuki 2y ago

Run an LLM in a browser…? WebNN!

mepian 2y ago

I agree, 640K ought to be enough for anybody.