Re:Replacing JavaScript Hot Path with WebAssembly
by fulafel on Friday February 15, 2019 @05:45AM
(#19169881)
To add background, this is a standard optimization technique that has been employed in eg fortran compilers since at least the 1980s.
Re:Replacing JavaScript Hot Path with WebAssembly
by Asooka on Friday February 15, 2019 @06:15AM
(#19169978)
Doesn't this rely on the CPU prefetching the memory to cache? Do current CPUs from Intel&AMD detect access patterns like this successfully? I.e. where you're accessing 64-element slices from a bigger array with a specific stride.
Re:Replacing JavaScript Hot Path with WebAssembly
by fulafel on Friday February 15, 2019 @08:13AM
(#19170591)
The idea is that the Y dimension is going to have a limited nr (here 64) of hot cache lines while a tile is processed.
After going through one set of 64 vertical lines, the Y accesses are going to be near the Y accesses from the previous outer-tile-loop iteration.
(Stride detecting prefetch can help, especially on the first iteration of a tile, but is not required for a speedup).
BTW this is the motivation for GPUs (and sometimes other graphics applications) using "swizzled" texture/image formats, where pixels are organised into various kinds of screen-locality preserving clumps. https://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-...
WASM example would speed up as well using the same approach. Or C, Rust or whatever.