Article: AMD's Mobile Strategy
By: hobold (hobold.delete@this.vectorizer.org), December 23, 2011 8:26 am
Room: Moderated Discussions
Linus Torvalds (torvalds@linux-foundation.org) on 12/22/11 wrote:
---------------------------
[...]
>The #1 thing for
>caches is not "size" - it's "locality". Sure, size matters,
>but size matters less than locality.
>
There used to be times when caches were generally never big enough, and size did matter a lot back then. Times have changed, and old habits are hard to give up. So yes, these days locality is a lot more important. CPU cache sizes tend to be rather luxurious. I have begun to view last level caches not as caches, but as tightly integrated main memory on the chip. DRAM is just the top level of the swap storage hierarchy. :-)
Anyways, back to the nits. I am not sure if caches are still the driving factor for locality. This modern style of stream processing massive amounts of data from main memory also requires very good locality to work well. The memory layout of data, cached or not, has become more and more important for the speed of such algorithms over the years.
So I wonder if maybe it's really the other way 'round? The size of caches has made locality concerns somewhat moot (you very often get away with not thinking about it at all for non-streamed data), but this only emphasizes how much main memory performance depends on the locality of accesses.
---------------------------
[...]
>The #1 thing for
>caches is not "size" - it's "locality". Sure, size matters,
>but size matters less than locality.
>
There used to be times when caches were generally never big enough, and size did matter a lot back then. Times have changed, and old habits are hard to give up. So yes, these days locality is a lot more important. CPU cache sizes tend to be rather luxurious. I have begun to view last level caches not as caches, but as tightly integrated main memory on the chip. DRAM is just the top level of the swap storage hierarchy. :-)
Anyways, back to the nits. I am not sure if caches are still the driving factor for locality. This modern style of stream processing massive amounts of data from main memory also requires very good locality to work well. The memory layout of data, cached or not, has become more and more important for the speed of such algorithms over the years.
So I wonder if maybe it's really the other way 'round? The size of caches has made locality concerns somewhat moot (you very often get away with not thinking about it at all for non-streamed data), but this only emphasizes how much main memory performance depends on the locality of accesses.