Quote from: vertigo on March 23, 2022, 05:31:01
Coming that close despite a 300MHz lower base and turbo and a lower voltage is pretty good, especially considering the restraints mentioned. That indicates it would likely be a fair bit faster at the same speeds, and that for equal performance it's going to require less power, which is great for laptops. And, of course, it's a new technology, so will likely improve with time. I'd say it looks promising, even if maybe not quite as much as hyped.
"Faster" at what? Cache only improves latency when fetching data from memory. You work at the same pace, you just idle less. To benefit from making a cache larger, active dataset must be larger than the old cache. Yes, there are applications that will benefit from it. The question is, however, will your applications benefit from it?
Understandably, you see a much larger effect in a multi-threaded benchmark because it's a shared cache. The more threads are running, the bigger the active dataset, the more likely it is that the smaller cache will be saturated.
When you have a code that does heavy lifting, it pays to optimize it and part of it is making it cache-friendly. Meaning, you don't want to be jumping all over the memory. When you fetch a chunk of data from memory, you want to do everything you need with it then and there before dumping it and fetching another. If at all possible. Instead of returning to it repeatedly. Or at least access data in such a way that predictor works well and can pre-fetch it in the background. Of course, the bigger the cache you're optimizing for, the more manoeuvring space you have to work with. But L3 is relatively far away. Therefore, such algorithms won't see much improvement. They're designed to minimize idling. The problem is that many developers are too lazy these days. :-) When it's a fun exercise.