Hacker News Reader

Comment by jsheard | Hacker News Reader

Has anyone benchmarked 64bit memory on the current implementations? There's the potential for performance regressions there because they could exploit the larger address space of 64bit hosts to completely elide bounds checks when running 32bit WASM code, but that doesn't work if the WASM address space is also 64bit.

View on HN

> WebAssembly apps tend to run slower in 64-bit mode than they do in 32-bit mode. This performance penalty depends on the workload, but it can range from just 10% to over 100%—a 2x slowdown just from changing your pointer size.

> This is not simply due to a lack of optimization. Instead, the performance of Memory64 is restricted by hardware, operating systems, and the design of WebAssembly itself.

https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...

Oof, that's unfortunate. I'm sure there's good reasons why WASM works like it does but the requirement for OOB to immediately abort the program seems rough for performance, as opposed to letting implementations handle it silently without branching (e.g. by masking the high bits of pointers so OOB wraps around).

Is this WASM specific though? Some apps suffer in performance when they move to 64-bit in general due to larger pointers and not taking sufficient advantage of/or needing 64-bit data types in general, hence the increased memory bandwidth/cache space slows them down (one of the reasons many people like a 32-bit address space, 64-bit data model).

The blog post explains that it's more than that. Bounds checking, in particular, costs more for reasons having to do with browser implementations, for example, rather than for architectural reasons.

Reply on news.ycombinator.com