3 ms·
On the other hand, I keep hearing people saying than nm is increasingly just a marketing number - and indeed, for all of Intel’s difficulties I don’t see too ma
by jl6 7y ago
On the other hand, I keep hearing people saying than nm is increasingly just a marketing number - and indeed, for all of Intel’s difficulties I don’t see too many chips beating Intel in single-threaded performance.
I say this as someone who bought a Ryzen-based system last year after significant research.
- gameswithgo 7y agothe transistors are actually getting smaller, that just doesn’t lead to more clock rate any more
- navaati 7y agoBut less heat, which allows you to cram more stuff in a package, which is a win !
- lonelappde 7y agoBut nm isn't measuring transistor sie. nm refers to size of an ambiguous "feature".
- jdietrich 7y agoIntel's advantage is architectural, not process. That architectural advantage has started to look extremely shaky after Meltdown/Spectre/Spoiler/etc - Intel gained a lot of performance through speculative execution at the cost of correctness.
- unlinked_dll 7y agoThis is purely speculative but based on my own experience. I firmly believe that real world performance is bottlenecked by cache before the slight difference in OoE/pipelines/speculation between Intel and AMD's CPUs. And the metric I really care about is the time it takes to read a cache line and the cache miss penalty. Those two fundamental pieces of the system are the ultimate bottleneck that developers can't deal with. It's really easy to construct cases where one CPU beats another in either single or multithreaded performance. The hard thing to make a judgement on is how it looks in real world software, and the more cumulative benchmarks are more telling of the quality of the software you bench other than the CPU. Particularly because optimizing for cache is so difficult. It's trivial to hit the memory wall and decide that's it, but it's really hard to decide that your entire architecture was flawed, choice of language was wrong, choice of algorithm or data structure was wrong, etc, A/B two different implementations and pick one that's slightly faster. The ROI isn't there. There's a philosophical point here though about the nature of "better" as it applies to the real world that makes my belief moot, because even if I'm right it when X% of software that people use runs Y% faster on a particular architecture it doesn't matter if it's because developers wrote and benched their code on that architecture. It's still "better." All that said, I'm very happy with my Zen2 purchase.
- gameswithgo 7y agoreal world performance includes software that can avoid cache misses (most games) and code that can’t (most compilers). It is good to make caches bigger and faster especially for less carefully engineered software which tends to have many layers of indirection, and a jit, and a garbage collector all putting pressure on the caches. smaller transistors helps us get bigger l3 caches which is something that helps zen2 compile code pretty fast! zen3 makes that l3 unified so it will be effectively bigger still making l1 and l2 caches bigger is problematic as that also makes them slower.