> 5 years from now people will grok more fundamentally that launching 2 process nodes ahead of Intel via TSMC was the big win.
AMD will have process node parity with Apple this year - Zen4 will be on N5P, as will M2. I doubt that alone will be sufficient for x86 to catch up, they have a LOT of ground to make up.
(this is, of course, the "small" laptop chip for Apple, the M2 Pro/Max will add more CPU cores and a much larger GPU, but you can still extrapolate the performance trends once we see Zen4 and I doubt it's going to be all that flattering. AMD has said "minimum of 15% faster", but even if that works out to 40% on average, Apple just made their own 18% leap, and the current architectural gap is much larger than 22% according to SPEC2017 benchmarks.)
It's not all just "apple wants to go bigger" either - Apple's cores are quite svelte in terms of transistor count as well, they're in between Zen3 and Alder Lake transistor count (this is supposition, but I think they would still be slightly smaller than Alder Lake even if you removed the AVX-512 support from Alder Lake). Most of their transistors go towards a truly titanic GPU, the cores themselves are fairly small (the efficiency cores in particular are impressively small for the performance they give).
And yes, of course "Apple has chosen to target slightly lower clock rates with really high IPC", but that is enabled by design decisions that ARMv8 allows (really deep reorder buffer, really wide decode) that x86 cannot replicate as easily, you can't just triple x86's IPC by targeting a slightly lower clockrate and going wider.
And yes, ARM code is slightly less dense - about 12% larger than x86 when compiling the SPEC2017 test suite, according to the numbers from the RISC-V people. That's not where the difference comes from either, it's not just "high IPC on low density code".
I know what Jim Keller said, and he's right, x86 isn't dead, but it's not ahead right now either, even considering Apple is on 5nm. When AMD is on 5nm this year, we can re-assess and see whether that was the driving factor, or whether there are design reasons as well.
People seem to have interpreted Keller's comments as being "it is physically impossible for ISA to make any perceptible difference in perf-per-transistor or perf-per-watt" and I'm not sure that's a statement he would agree with. A 10-20% advantage to restructuring your architecture in a way that enables deeper reorder and better decoding vs x86, seems like a reasonable premise to me. Especially considering the baseline is x86, the quintessential legacy behemoth ISA. There has been a lot of work to keep it in play, but that means a lot of the "easy tricks" like instruction cache have already been exploited just to get it this far. Surely there are things that could have been done better from a clean start.