Re:Replacing JavaScript Hot Path with WebAssembly
by vardump on Friday February 15, 2019 @02:14AM
(#19169070)
No, it's faster because the working set of 64 * 64 * 4 * 2 bytes can (almost) fit in CPU core L1 cache. Further cache levels are slower and finally the memory is glacially slow.
WASM example would speed up as well using the same approach. Or C, Rust or whatever.
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-...
My guess is that if you try to invoke initial whole code (before tiling) in a external loop (rotating images of exactly the same size), you will get similar perf boost (not that it has practical implication, but just to understand how optimization works).