4 ms·

I, on the other hand, wish everyone would embrace 32 bit by default. Doubling the size of every index, integer, etc comes at significant memory cost for next to

by gpm 7y ago

I, on the other hand, wish everyone would embrace 32 bit by default. Doubling the size of every index, integer, etc comes at significant memory cost for next to no benefit. Increasing the amount of memory used directly impacts performance considering how slow memory is and how important it is to keep commonly used items in cache. If you're seriously using more than 4gb in a web page... I wouldn't mind a non-default wasm64 format. You should also be considering shipping a native app at that point, wasm is not free in terms of performance.

centimeter 7y ago
> Doubling the size of every index, integer, etc comes at significant memory cost for next to no benefit. The overwhelming majority of GUI program data is composed of images, textures, sounds, videos, 3D models, text, etc. I would bet that less than 5% of the memory required to host a popular web page (facebook, amazon, etc.) is dedicated to pointers, array indices, etc.
- gpm 7y ago
  The overwhelming majority of what wasm will be used for probably does not include images, textures, sounds, videos or 3d models. The overwhelming majority of the memory in most wasm programs will probably be not large arrays of text. The webpage as a whole is a gui program, but wasm is primarily a place to run computationally intensive code. The web-browser deals with things like rendering images natively without storing the image in wasm.
  - monocasa 7y ago
    What do you think that computationally expensive code is cranking on? It ain't small bits of text.
    - deleted 7y ago
      [deleted]
    - gpm 7y ago
      When it is text, it's usually more small bits of text than big bits. If you're just copying around giant strings you're unlikely to be using webasm. More likely you're copying around tons of small strings as you format them into a giant string if that's the end goal. Or you're copying around tons of small strings as you use those small strings to make api calls to the dom (indirectly through js). Or you're just plain running something like a physics simulation and don't even have text in the first place.
  - xscott 7y ago
    Honestly, I don't like the trend of web apps for everything, and I'd be ok if web pages couldn't really be more than toy programs. However, at that point, why even bother with WASM? I mean what is that even for if you're not doing real computation on real data sets? Real data sets are bigger than 2 billion sometimes...
    - gpm 7y ago
      If you've got 2GB of data and you're doing it in WASM... you're probably doing something wrong, for the simple reason that that means you probably loaded 2GB of data over the internet into the browser (and will probably need to redo that every time you revisit the page). That's enough data that you want to save it to disk, which means (probably) not using a browser. As for "what is the point if not doing computation on "real" data sets"... letting you do computation on reasonably sized data sets. Consider that the size of a gaint codebase like linux is still only a few hundred megabytes (uncompressed). That's more than enough data to be doing interesting work. Or look at the size of a game like quake3.
      - xscott 7y ago
        > for the simple reason that that means you probably loaded 2GB of data over the internet No, web pages can access local storage.
        gpm 7y ago
        You mean file:// urls? If you have access to do that... why not just install a real executable as well. (Can't say I'm terribly up to date on the different ways to store data as a website... but if there's a way to persist multiple gb I would be very surprised)
        xscott 7y ago
        I really don't like being in the position of defending web apps - that is really not my preferred way to do most things I would write. However, taking a devil's advocate position: > You mean file:// urls? If you have access to do that... Modern browsers provide JavaScript with way more power than just file urls: https://www.w3.org/TR/FileAPI/ https://www.w3.org/TR/FileAPI/ There are also drag and drop APIs... > why not just install a real executable as well. That depends on who your audience is. It's certainly easier to tell some users "go hit this web page and click ok when it asks to open your file". And there are some web apps which I find preferable to downloaded apps. For instance, I really like draw.io, and it works seamlessly on Windows, MacOS, and Linux. > but if there's a way to persist multiple gb I would be very surprised The only limitations I'm aware of are tied to this nonsense about 32 bit integers :-)
- Hokusai 7y ago
  You are probably right about the heap, but in the stack there are no big data structures. To move all data types to 64bits would impact the stack size of processes and threads. Bigger data structures also mean more cache misses. So, systems would be also slower. As, bringing data from memory to the CPU is very slow compared with accessing L1 or L2 cached data. So, you have a point. But, it does not apply equally to all data.
  - xscott 7y ago
    Let's take an example in your favor and say you've got 16 integer local variables per stack frame and you're recursing 1000 (!!!) times over some really unbalanced tree or such. You saved 64 kilobytes... Ok, now let's say 32 bit integers are the standard: You either wrote a program that starts to fail in mysterious ways when someone runs it on a 2 GB file, or you complicated the hell out of your data structures by needing arrays of arrays (i.e. https://www.nayuki.io/page/large-arrays-proposal-for-java https://www.nayuki.io/page/large-arrays-proposal-for-java). It should be easier to make correct programs.
- jfkebwjsbx 7y ago
  You would lose your money, because most of that is not needed in RAM, and definitely not in cache.
  - centimeter 7y ago
    The browser stores all of that stuff in RAM.
skunkworker 7y ago
On some platforms like ARM, the transition from 32bit to 64bit(Aarch64) and the improvements to the ISA allowed some software to run much quicker on the same hardware. While the increased memory usage was detrimental if you are running into memory pressure issues, the speed improvements would be well worth the change for most tasks. When the Pi 3 launched it had a 32bit OS, but switching to 64bit improved the speed from 15 to 30% at the cost of 1.5X larger memory size.[1] [1] https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-instructions-boost-performance-by-15-to-30-compared-to-32-bit-arm-aarch32-instructions/ https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-i...
- gpm 7y ago
  There doesn't have to be a choice between a fast ISA, and even 64 bit registers, and using 32 bit pointers/indices. We can do theoretically do both - it's just extremely rare in practice.
  - kllrnohj 7y ago
    Not rare at all. 32-bit "pointers" in a 64-bit process is relatively common, even, as it's what ART does on Android ( https://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/3 https://www.anandtech.com/show/8231/a-closer-look-at-android... ). And Hotspot has a similar optimization: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
    - Dylan16807 7y ago
      And it's also common to truncate 64 bit pointers down to 48 bits to pack other info alongside them, since those are the only bits that actually get used on most architectures.

by gpm 7y ago

centimeter 7y ago

> Doubling the size of every index, integer, etc comes at significant memory cost for next to no benefit. The overwhelming majority of GUI program data is composed of images, textures, sounds, videos, 3D models, text, etc. I would bet that less than 5% of the memory required to host a popular web page (facebook, amazon, etc.) is dedicated to pointers, array indices, etc.

gpm 7y ago
The overwhelming majority of what wasm will be used for probably does not include images, textures, sounds, videos or 3d models. The overwhelming majority of the memory in most wasm programs will probably be not large arrays of text. The webpage as a whole is a gui program, but wasm is primarily a place to run computationally intensive code. The web-browser deals with things like rendering images natively without storing the image in wasm.
- monocasa 7y ago
  What do you think that computationally expensive code is cranking on? It ain't small bits of text.
  - deleted 7y ago
    [deleted]
  - gpm 7y ago
    When it is text, it's usually more small bits of text than big bits. If you're just copying around giant strings you're unlikely to be using webasm. More likely you're copying around tons of small strings as you format them into a giant string if that's the end goal. Or you're copying around tons of small strings as you use those small strings to make api calls to the dom (indirectly through js). Or you're just plain running something like a physics simulation and don't even have text in the first place.
- xscott 7y ago
  Honestly, I don't like the trend of web apps for everything, and I'd be ok if web pages couldn't really be more than toy programs. However, at that point, why even bother with WASM? I mean what is that even for if you're not doing real computation on real data sets? Real data sets are bigger than 2 billion sometimes...
  - gpm 7y ago
    If you've got 2GB of data and you're doing it in WASM... you're probably doing something wrong, for the simple reason that that means you probably loaded 2GB of data over the internet into the browser (and will probably need to redo that every time you revisit the page). That's enough data that you want to save it to disk, which means (probably) not using a browser. As for "what is the point if not doing computation on "real" data sets"... letting you do computation on reasonably sized data sets. Consider that the size of a gaint codebase like linux is still only a few hundred megabytes (uncompressed). That's more than enough data to be doing interesting work. Or look at the size of a game like quake3.
    - xscott 7y ago
      > for the simple reason that that means you probably loaded 2GB of data over the internet No, web pages can access local storage.
      - gpm 7y ago
        You mean file:// urls? If you have access to do that... why not just install a real executable as well. (Can't say I'm terribly up to date on the different ways to store data as a website... but if there's a way to persist multiple gb I would be very surprised)
        xscott 7y ago
        I really don't like being in the position of defending web apps - that is really not my preferred way to do most things I would write. However, taking a devil's advocate position: > You mean file:// urls? If you have access to do that... Modern browsers provide JavaScript with way more power than just file urls: https://www.w3.org/TR/FileAPI/ https://www.w3.org/TR/FileAPI/ There are also drag and drop APIs... > why not just install a real executable as well. That depends on who your audience is. It's certainly easier to tell some users "go hit this web page and click ok when it asks to open your file". And there are some web apps which I find preferable to downloaded apps. For instance, I really like draw.io, and it works seamlessly on Windows, MacOS, and Linux. > but if there's a way to persist multiple gb I would be very surprised The only limitations I'm aware of are tied to this nonsense about 32 bit integers :-)
Hokusai 7y ago
You are probably right about the heap, but in the stack there are no big data structures. To move all data types to 64bits would impact the stack size of processes and threads. Bigger data structures also mean more cache misses. So, systems would be also slower. As, bringing data from memory to the CPU is very slow compared with accessing L1 or L2 cached data. So, you have a point. But, it does not apply equally to all data.
- xscott 7y ago
  Let's take an example in your favor and say you've got 16 integer local variables per stack frame and you're recursing 1000 (!!!) times over some really unbalanced tree or such. You saved 64 kilobytes... Ok, now let's say 32 bit integers are the standard: You either wrote a program that starts to fail in mysterious ways when someone runs it on a 2 GB file, or you complicated the hell out of your data structures by needing arrays of arrays (i.e. https://www.nayuki.io/page/large-arrays-proposal-for-java https://www.nayuki.io/page/large-arrays-proposal-for-java). It should be easier to make correct programs.
jfkebwjsbx 7y ago
You would lose your money, because most of that is not needed in RAM, and definitely not in cache.
- centimeter 7y ago
  The browser stores all of that stuff in RAM.

skunkworker 7y ago

On some platforms like ARM, the transition from 32bit to 64bit(Aarch64) and the improvements to the ISA allowed some software to run much quicker on the same hardware. While the increased memory usage was detrimental if you are running into memory pressure issues, the speed improvements would be well worth the change for most tasks. When the Pi 3 launched it had a 32bit OS, but switching to 64bit improved the speed from 15 to 30% at the cost of 1.5X larger memory size.[1] [1] https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-instructions-boost-performance-by-15-to-30-compared-to-32-bit-arm-aarch32-instructions/ https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-i...

gpm 7y ago
There doesn't have to be a choice between a fast ISA, and even 64 bit registers, and using 32 bit pointers/indices. We can do theoretically do both - it's just extremely rare in practice.
- kllrnohj 7y ago
  Not rare at all. 32-bit "pointers" in a 64-bit process is relatively common, even, as it's what ART does on Android ( https://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l/3 https://www.anandtech.com/show/8231/a-closer-look-at-android... ). And Hotspot has a similar optimization: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops https://wiki.openjdk.java.net/display/HotSpot/CompressedOops
  - Dylan16807 7y ago
    And it's also common to truncate 64 bit pointers down to 48 bits to pack other info alongside them, since those are the only bits that actually get used on most architectures.