Re:Up to 4GB of Memory in WebAssembly
by Avi-D-coder on Thursday May 14, 2020 @07:20PM
(#23186839)
Why prefer 64bit pointers over multiple memory address spaces (https://github.com/WebAssembly/multi-memory)?
Your CPU has to do a lot of work to keep pretending it's memory is flat, If we give up that pretense you can optimize cache utilization and multiplex multiple WASM threads onto a single OS thread without allowing specter.
[ Parent
| on HN ]
Because the CPU is going to do the work to make that illusion happen regardless of if you participate in it or not - so why constrain yourself to anything less than 64-bit pointers if you're not going to get anything in return?
What cache optimization are you referring to? Just that 32-bit pointers is a form of pseudo-compression and can be more densely packed? Because there's not really any other cache benefits in play here, and you don't need 32-bit compressed pointers to get optimized cache utilization - value types & data oriented design is far more effective for improving cache utilization.
Re:Up to 4GB of Memory in WebAssembly
by Avi-D-coder on Thursday May 14, 2020 @10:35PM
(#23188244)
Immutable data structures tend to use a lot of pointers see how Haskell executes, even in other paradigms halving pointer s can have a significant impact on alignment (tags, enums, etc).
V8 sandboxes WASM by placing them in a dedicated OS process, this buys 64 bit pointers, but comes at a cost. We can chose for a 64 bit processor to buy us in process memory isolation, by masking pointers or we can have 64 bit pointers.