3 ms·

> 1. L1, L2, L3 cache sizes. Since these are implemented as S-RAM, they can drastically increase chip area, and hence cost. The larger the cache the higher the

> 1. L1, L2, L3 cache sizes. Since these are implemented as S-RAM, they can drastically increase chip area, and hence cost. The larger the cache the higher the lookup latency becomes. That's why L1 and L2 rarely increase in size. Athlon XP: 64+64 kB L1I/D (ok, this one had bigger caches than the competition, 16/32kB was more usual in that time frame); 256 kB L2 Zen: 64+32 kB L1I/D; 512 kB L2 Pentium III Tualatin: 16+16 LkB 1I/D; 256-512 kB L2 Skylake: 32+32 kB L1I/D; 256 kB L2

writepub 8y ago
You mean there's an upper limit to performance benefits of increasing cache sizes. The more important comparison is between a desktop CPU and ARM mobile. You'll quickly notice performance parity when cache sizes are increased on the mobile CPUs. And also notice Qualcomm's 845 and earlier lagged Apple's CPUs in cache size. The performance gains certainly plateau, but mobile caches weren't even trying to approach this limit, till now - explaining a big part of the performance gap between desktop and mobile
- blattimwind 8y ago
  > You mean there's an upper limit to performance benefits of increasing cache sizes. A cache is a latency-hiding device over a working set of unknown size. The latency of the cache depends on its size. So picking a cache size embodies a huge set of unknowns (the programs that will be run, their working set sizes, latency and size of main and swap memories etc.). In any case, for a given workload you could draw up a graph of cache size (and implied cache latency) vs throughput / latency and see that there is a sweet spot (larger cache does not substantially increase performance, but rather degrades it, due to increased cache latency). Furthermore, when you do a shrink, you could put the implied performance gains into making a bigger cache of the same (absolute) latency, or making a cache of the same size with lower latency; the latter might be implicitly required since you now probably have a faster core that wants a cache with lower absolute latency.

writepub 8y ago

You mean there's an upper limit to performance benefits of increasing cache sizes. The more important comparison is between a desktop CPU and ARM mobile. You'll quickly notice performance parity when cache sizes are increased on the mobile CPUs. And also notice Qualcomm's 845 and earlier lagged Apple's CPUs in cache size. The performance gains certainly plateau, but mobile caches weren't even trying to approach this limit, till now - explaining a big part of the performance gap between desktop and mobile

blattimwind 8y ago
> You mean there's an upper limit to performance benefits of increasing cache sizes. A cache is a latency-hiding device over a working set of unknown size. The latency of the cache depends on its size. So picking a cache size embodies a huge set of unknowns (the programs that will be run, their working set sizes, latency and size of main and swap memories etc.). In any case, for a given workload you could draw up a graph of cache size (and implied cache latency) vs throughput / latency and see that there is a sweet spot (larger cache does not substantially increase performance, but rather degrades it, due to increased cache latency). Furthermore, when you do a shrink, you could put the implied performance gains into making a bigger cache of the same (absolute) latency, or making a cache of the same size with lower latency; the latter might be implicitly required since you now probably have a faster core that wants a cache with lower absolute latency.