[Beowulf] [EXTERNAL] Re: Deskside clusters

[Lawrence Stewart]

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 <jcownie at 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 <hearnsj at gmail.com <mailto:hearnsj at gmail.com>> wrote:
>> 
>> Eadline's Law : Cache is only good the second time.
>> 
>> On Fri, 17 Sep 2021, 21:25 Douglas Eadline, <deadline at eadline.org <mailto:deadline at 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 at beowulf.org <mailto:Beowulf at 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 at beowulf.org <mailto:Beowulf at 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 <jcownie at gmail.com <mailto:jcownie at gmail.com>>
> Mob: +44 780 637 7146
> 
> 
> 
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit https://beowulf.org/cgi-bin/mailman/listinfo/beowulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://beowulf.org/pipermail/beowulf/attachments/20210920/e6d1755d/attachment.htm>