Well said. Expanding on this, caches work because of both temporal locality and spatial locality. Spatial locality is addressed by having cache lines be substantially larger than a byte or word. These days, 64 bytes is pretty common. Some prefetch schemes, like the L1D version that fetches the VA ^ 64 clearly affect spatial locality. Streaming prefetch has an expanded notion of “spatial” I suppose!
What puzzles me is why compilers seem not to have evolved much notion of cache management. It seems like something a smart compiler could do. Instead, it is left to Prof. Goto and the folks at ATLAS and BLIS to figure out how to rewrite algorithms for efficient cache behavior. To my limited knowledge, compilers don’t make much use of PREFETCH or any non-temporal loads and stores either. It seems to me that once the programmer helps with RESTRICT and so forth, then compilers could perfectly well dynamically move parts of arrays around to maximize cache use. -L > On 2021, Sep 20, at 6:35 AM, Jim Cownie <jcow...@gmail.com> wrote: > >> Eadline's Law : Cache is only good the second time. > > Hmm, that’s why they have all those clever pre-fetchers which try to guess > your memory access patterns and predict what's going to be needed next. > (Your choice whether you read “clever” in a cynical voice or not :-)) > *IF* that works, then the cache is useful the first time. > If not, then they can mess things up royally by evicting stuff that you did > want there. > >> On 19 Sep 2021, at 12:02, John Hearns <hear...@gmail.com >> <mailto:hear...@gmail.com>> wrote: >> >> Eadline's Law : Cache is only good the second time. >> >> On Fri, 17 Sep 2021, 21:25 Douglas Eadline, <deadl...@eadline.org >> <mailto:deadl...@eadline.org>> wrote: >> --snip-- >> > >> > Where I disagree with you is (3). Whether or not cache size is important >> > depends on the size of the job. If your iterating through data-parallel >> > loops over a large dataset that exceeds cache size, the opportunity to >> > reread cached data is probably limited or nonexistent. As we often say >> > here, "it depends". I'm sore someone with better low-level hardware >> > knowledge will pipe in and tell me why I'm wrong (Cunningham's Law). >> > >> >> Of course it all depends. However, as core counts go up, a >> fixed amount of cache must get shared. Since the high core counts >> are putting pressure on main memory BW, cache gets more >> important. This is why AMD is doing V-cache for new processors. >> Core counts have outstripped memory BW, their solution >> seems to be big caches. And, cache is only good the second time :-) >> >> >> -- big snip-- >> >> -- >> Doug >> >> _______________________________________________ >> Beowulf mailing list, Beowulf@beowulf.org <mailto:Beowulf@beowulf.org> >> sponsored by Penguin Computing >> To change your subscription (digest mode or unsubscribe) visit >> https://beowulf.org/cgi-bin/mailman/listinfo/beowulf >> <https://beowulf.org/cgi-bin/mailman/listinfo/beowulf> >> _______________________________________________ >> Beowulf mailing list, Beowulf@beowulf.org <mailto:Beowulf@beowulf.org> >> sponsored by Penguin Computing >> To change your subscription (digest mode or unsubscribe) visit >> https://beowulf.org/cgi-bin/mailman/listinfo/beowulf >> <https://beowulf.org/cgi-bin/mailman/listinfo/beowulf> > > -- Jim > James Cownie <jcow...@gmail.com <mailto:jcow...@gmail.com>> > Mob: +44 780 637 7146 > > > > > _______________________________________________ > Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing > To change your subscription (digest mode or unsubscribe) visit > https://beowulf.org/cgi-bin/mailman/listinfo/beowulf
_______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit https://beowulf.org/cgi-bin/mailman/listinfo/beowulf
