L3 Cache

intel did L4 cache with like 128MB of on-die eDRAM with broadwell. Then removed it on memelake. However, the broadwell i7-5775C outperforms the i7-6700.

>>57786454
See what I mean? Why would they go backwards like that?

>>57786368
>And then Intel got into it, but it doesn't seem that they went as all-in with L3 cache on their designs as AMD did.
They do, look at high core count Xeons. I have 50MB in my workstation.

>>1 x 1 GB L3 cache
because cache takes up a lot of die space

>>57786454
It does not perform better. That cache was for the iGpu, which was more powerful than the other. But no.

>>57786368
My chip has 35mb L3 cache

xeon e5 2683v3 master race

Because it doesn't matter as much for good applications. Yes. For shitty applications it matters a lot but hardware nerds don't care about that.

And even so you'd have to have very significant cache to actually manage to run these cache unfriendly applications well. Probably more than what's feasible.

So it doesn't matter for now.
And I personally would prefer a more even distribution between the cache sizes than you suggest.

If the CPU has a long pipeline, you will want a large cache. If it's short, it will still help but it wont be as important.

File: 1441544266797.jpg (172KB, 750x565px) Image search: [Google]

172KB, 750x565px

>>57786368
Have you tried reading up on the subject instead of being a retard?
1. Cache takes a bunch of transistors, and consequently a bunch of die space. Die space is expensive.
2. In modern processors, cache misses are barely a thing. You're proposing "fixing" something that isn't a problem.
3. Smaller caches are faster, bigger caches are slower. Period. It's impossible to get around that. That's why we have multi-level cache structures. Not only would your idea of bloated cache sizes be useless, it'd actually significantly harm performance.

Fuck your shitty post formatting, by the way.

>>57789643
Dumb weeb

>>57789643
>2. In modern processors, cache misses are barely a thing. You're proposing "fixing" something that isn't a problem.
Cache missed are why hyper threading is a exists, so the CPU can continue to do work while a core is stalled waiting for memory to load.

>>57786368
caches have one single purpose: to make access to memory faster
today's cpus achieve over 95% cache hit rate, we are getting to the point of diminishing returns
most consumers don't benefit much from huge caches
most software used by consumers isn't optimized to reduce cache hits anyway so a smaller but lower latency cache is probably better

same thing applies to core count, most consumers don't need more than 4 cores

>https://www.extremetech.com/extreme/188776-how-l1-and-l2-cpu-caches-work-and-why-theyre-an-essential-part-of-modern-chips

>>57786368
gaymen

>>57791880
The cache hit rate is actually higher than that, depending on what you specifically mean. L1 has a ~95% hit rate these days, like you said. If L1 misses it goes to L2, which has a 90% or so hit rate. L2 fails and in comes L3 with a hit rate in the 70% ballpark if I remember correctly. Overall you can get a hit in one of the three caches roughly 99.85% of the time, with the minuscule L1 handling 95% of it, the bigger L2 getting another 4.5%, and the meaty L3 netting us our last 0.35%. Following this trend, a large L4 cache with an estimated 50% hit rate could add another 0.08%. It'll cost a pretty penny though, and with latencies approaching that of RAM there'd be little performance increase even when it did get a hit.

>>57786368
the physically bigger a cache is, the more nanoseconds it takes to physically retrieve data, and hit rates are already quite high.

doubling the size/area might for example increase latency by 50% and only eliminate something like 10% to 30% of the remaining misses.