Why don't more CPUs have L4 Cache?

It's only really useful during a few niche use cases.

It is amazing for integrated graphics purposes.

>>59057474
>learned about I cache and D cache last week
>felt like that was the coolest shit ever
I'm too easily impressed. Help.

I thought anything with iris/iris pro can use the edram as l4 cache

>>59057474
You hit the point of diminishing gains, since even tiny L1 caches have >90% hit rates, L2s have high 90s percentage hits, and so on.

Since a cache also has to detect a miss before sending a request to the next layer, you need to be sure that the next cache layer you add actually has the right size to cover a meaningfully big slice of the remaining misses, since you necessarily add some latency with each step.

Something like the Iris Pro L4 works since game rendering has a huge amount of frame-to-frame data locality and all the buffers, textures, etc. can fit in 64 or 128 MB. But it also carries a big cost, for the eDRAM, the on-die controller logic, interposer, more complex assembly, etc.

>>59057742
Why don't they just make the L2 cache bigger and not bother with L3?

>>59057474
Huge L4 caches work for iGPUs/APUs, but it's a double edge sword for server chips.

Maintaining coherent caches requires a lot of bookkeeping traffic between chips, and the most common way of alleviating this is keeping tables of what's stored in other caches (called snoop filter tables), and this starts ballooning in size and cost if every CPU has huge caches bolted on.

Whats the difference between these caches? L2, L3?

>>59057768
Larger caches increase latency. More stuff to store == more stuff to sift through. L1 is deliberately kept extremely small because seeking to individual memory cells has to be fast as shit or it wastes cycles. L2 used to be larger on average but recent CPUs have limited it to more modest sizes to keep latency down for similar reasons, instead they've added another level L3 to catch stuff that has been evicted from L2. L4 does the same but it's also used by iGPUs to improve bandwidth

File: Road-to-Zen_Architecture-Brief-6-1440x811.png (225KB, 1440x811px) Image search: [Google]

225KB, 1440x811px

>>59057768
cache design is all about tradeoffs.

physically bigger caches take more clock cycles to search and return data from, and caches with more bandwidth (more read/write ports, wider reads/write) need more size and power too.

most reads from a core can be serviced by moderately sized L1 and L2 caches, so you wouldn't want to increase die power and size a bunch just to barely increase hit rate. L3 cache can be slower, denser, and considerably more power frugal since it isn't expected to have to service too many requests.

>>59057792
it's just the order in which they attempt to service a request. L1 = small/fast/inefficient, L2 = bigger/not quite as fast/more efficient, and so on.

>>59057474
Why don't more CPUs have L9001 cache?

what are the speeds of those caches?

What does the L stand for?

>>59057504
Look up trace caches that are used in fetch/decode phases in OOO speculatively scheduled processors, like the i7. I am pretty sure all threads per actual CPU have their own trace cache as well.

>>59057474
>t.didn't go to college for CS
Larger the cache the slower it is to access it.

>>59060574
Level

>>59060557
Orders of magnitude faster than RAM.

>>59057474
Too much latency and too little help