[HN Gopher] Memory64
       ___________________________________________________________________
        
       Memory64
        
       Author : tosh
       Score  : 17 points
       Date   : 2024-11-07 10:27 UTC (3 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | lahcim2000 wrote:
       | 32GB in single browser window running web assembly...
       | 
       | Why would you ever want to go above this? What is your scenario?
        
         | dagmx wrote:
         | 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.
        
         | umvi wrote:
         | 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/).
         | 
         | 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.
        
       | jsheard wrote:
       | I'm curious to see what the performance impact of using 64bit
       | memory ends of being. WASM runtimes currently use a clever trick
       | on 64bit host platforms where they allocate a solid 4GB block of
       | virtual memory up front, and then rely on the MMU to catch out-
       | of-bounds accesses to unmapped pages, so bounds checking is
       | basically free. That won't work with 64bit WASM though so
       | runtimes will have to do old fashioned explicit bounds checking
       | on every single heap access.
        
       ___________________________________________________________________
       (page generated 2024-11-10 23:00 UTC)