4 ms·
Measuring the size of the cache line empirically
- phaker 3y agoIt 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.
- deleted 3y ago[deleted]
- IshKebab 3y agoWay 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.
- camel-cdr 3y agoDoesn'tcbo.zero just zero the cache, or am I missing something?
- hulitu 3y agoCPU-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 ?
- sliken 3y agoThe 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.