Measuring the size of the cache line empirically

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.

Then you should get MUCH cleaner graphs.

Way smooth graphs than I was expecting. Definitely in the second one you have to squint.

Btw on RISC-V you can find the cache line size directly using the `cbo.zero` instruction. Dunno about ARM/x86.

CPU-Z came some time ago with a "latency.exe" which was used to measure cache sizes and latencies. Anyone knows if the source is available somewhere ?