It and it's getting late here so i can't try it myself, at least not today, but i'd try moving in a fixed, sparse, pseudorandom pattern but vary operation size.
I think this should give a more staircase-y plot, with jumps when the size of each individual copy passes whole multiple of cache line width.
I think this way you don't need to fight prefetching, and there will be one read-modify-write per operation except right at the edges which is another signal.
The plots are pretty messy, clearly something is being missed.
To avoid prefetch (in the compiler or hardware level) for stride N shuffle the reads to make sure you read each cache line exactly onces. Then you'll hit TLB issues. To handle that either sort them within a fixed sized sliding window, or within the same page.
6 comments
[ 68.3 ms ] story [ 67.1 ms ] threadI think this should give a more staircase-y plot, with jumps when the size of each individual copy passes whole multiple of cache line width.
I think this way you don't need to fight prefetching, and there will be one read-modify-write per operation except right at the edges which is another signal.
Btw on RISC-V you can find the cache line size directly using the `cbo.zero` instruction. Dunno about ARM/x86.
To avoid prefetch (in the compiler or hardware level) for stride N shuffle the reads to make sure you read each cache line exactly onces. Then you'll hit TLB issues. To handle that either sort them within a fixed sized sliding window, or within the same page.
Then you should get MUCH cleaner graphs.