4 ms·
> 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 pari
by paulmd 4y ago
> 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.
- smoldesu 4y ago> 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. Quick note: AMD's 5nm offerings will not be using a big.LITTLE configuration, so direct comparison with the M1 would probably not be very accurate for the purposes of comparing power consumption.
- msbarnett 4y ago> Quick note: AMD's 5nm offerings will not be using a big.LITTLE configuration, so direct comparison with the M1 would probably not be very accurate for the purposes of comparing power consumption. Ok, but the second we start saying Intel or AMD needs to make architectural changes to match M1 performance/power consumption, that in and of itself is a refutation of the GP's argument that the only reason M1 looks good is the manufacturing node. We're admitting that there's an architectural component to its results.
- paulmd 4y agoAnd Intel has big.LITTLE but they're not using TSMC nodes. Apple comparisons run on OSX or Asahi Linux, which doesn't run x86, so the software/ecosystem is different. Etc etc. No comparison is ever perfect, you'll just have to take the best data we have and run with it. Complaining that a study isn't exactly perfect is trite, once you get beyond the "junior scientist makes obvious methodological error" tier it's honestly one of the least useful forms of criticism, someone is always going to think it should have been done better/differently (and wants you to take the time and spend the money to do it for them). But science is about doing the best you have and trying to make reasonable extrapolations about the things you can't. Single-thread benchmarks on big vs little cores will get you IPC figures, and then you can scale those according to clocks you see on full-load conditions, for example. Or you can simply compare it to a future 13th/14th gen Intel i3 with big.LITTLE, or an AMD quad-core APU. AMD has SMT, that's an advantage, Apple has single-threaded cores but a couple extra little cores, it's similar-ish. Nothing is ever perfect. You just make do. It doesn't mean we throw up our hands and scream that if we can't be accurate to 1000 decimal points then we can never truly know anything. (You may not have intended this, so just FYI: it kinda comes off like you're pre-stating that you won't accept the results if they don't come out the way you like, that you'll find some other difference between the two to latch onto. And there will always be some minor thing you can latch onto, no two designs are exactly identical. But that's not really an honest way to approach science, merely being able to theorize some differences isn't useful and if you feel strongly about it then you should do a similar test yourself to demonstrate.)