16 ms·

I thought the observation was always that instruction set was not such a big difference in high performance CPUs next to manufacturing technology which was by f

I thought the observation was always that instruction set was not such a big difference in high performance CPUs next to manufacturing technology which was by far the first order effect. It would be expected for a high performance ARM CPU to reach roughly the same performance in that case (AMD is 1 generation behind here, I think Intel is 2). Is there really "chipheads" who are predicting ARM ISA to buck this trend and start pulling ahead at equivalent technology nodes? By what mechanism do they believe this will happen, do you know?

entee 5y ago
Not a chiphead, but saw this in the article that might be a reason ARM is better for this kind of thing: "The theory goes that arm64’s fixed instruction length and relatively simple instructions make implementing extremely wide decoding and execution far more practical for Apple, compared with what Intel and AMD have to do in order to decode x86-64’s variable length, often complex compound instructions." Not sure it's true, not an expert. But it doesn't sound wrong!
- throwawaylinux 5y ago
  The fixed width decoders have always been a commonly cited advantage of fixed width, and to some degree it must be true. But this is not a recent thing, the "common wisdom" about instruction format not mattering too much still very much applies here. Pre-decode lengths or stop-bits and more recently micro-op caches have been techniques that x86 has used to mitigate this and improve front end widths, for example. People like Jim Keller (who has actually worked and lead teams implementing these very processors at Apple, Intel, and AMD!) basically say as much (while acknowledging decode is a little harder, in the large scheme of things on modern large cores it's not such a big deal): https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/ https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-... Andy Glew, one of the architects for Intel's first out of order x86 core (P6) among other things, is another who has said similar. https://groups.google.com/g/comp.arch/c/elke1FHfYr0/m/SwW9NT1x2gMJ https://groups.google.com/g/comp.arch/c/elke1FHfYr0/m/SwW9NT...
  - mhh__ 5y ago
    > X86 tax might be 5% A consistent 5% win is pretty huge for certain industries.
    - throwawaylinux 5y ago
      > A consistent 5% win is pretty huge for certain industries. Are you referring to Andy Glew's thread? He said perhaps 5%, but he also went on to say probably less than 5% for basically the lowest-end out of order processor that was fielded (A-9), not what you would call a high performance core (even then 10 years ago). On today's high performance cores? Not sure, extrapolating naively from what he said would suggest even less. Which is backed up by what Jim Keller says later. So << 5%, which is significantly less than process node generational increases. I'm not saying ARM won't leapfrog x86, I'm just asking what the basis is for that belief, and what those who believe it think they know that the likes of Jim Keller does not. If it's an argument about something other than details of instruction set implementation (e.g., economics or process technology) then that would be something. That is exactly how Intel beat the old minicomputer companies' RISCs despite having "x86 tax", is that they got revenues to fund better process technology and bigger logic design teams. Although that's harder to apply to Apple vs AMD/Intel because x86 PC and server units and revenues are also huge, and TSMC gives at least AMD a common manufacturing base even if Apple is able to pay for some advantage there.
    - TomVDB 5y ago
      Yes, but people aren't impressed by the M1 chips because of 5% KPI differences.
ant6n 5y ago
Mmh, perhaps the fixed width instruction set makes ultra wide decoders easier.
- dnautics 5y ago
  I am not a chiphead either (but I used to live with some) I think easier decoders => shorter pipeline, less silicon footprint for decode, possibly more silicon for reordering logic, less dark silicon, etc. To be fair the chipheads I lived with were gaga about VLIW, so there was certainly a bias there.
  - paulmd 5y ago
    I mean, VLIW is fantastic as long as you have very predictable workloads with high parallelism and little branching that are very easily statically scheduled. If you want to design a DSP or something, where you know it’ll be 100% saturated all the time with an absolutely predictable workload, it’s extremely efficient. Same for AMD Terascale GPUs back in the days before async compute and other GPGPU style tasks took over.
mhh__ 5y ago
Two thoughts: 1. The instruction set isn't so much a performance thing as much as a thing that bites you with power usage (you need to have a big fat decoder on all the time in the worst case). The widest X86's can only dispatch 75% of the instruction per cycle but X86 instructions can do more, so you'd have to check a specific benchmark. 2. I want X86 to die more because it's fucking ugly than performance as per se. ARM is not a simple ISA, so although you won't be writing a disassembler in 10 minutes like RISC-V, aarch64 is still much less insane than X86 with all the extensions.
- Osiris 5y ago
  The vast majority of developers will never even see assembly for x86 or ARM. Compiler developers and those need to hand optimize code may care but for everyone else it's a black box.
  - mhh__ 5y ago
    Sure but I am part of that latter category. The unwashed masses don't have to care and won't actually use the performance, I'm not that bothered whether they care or not, although it's worth saying that X86 is such a mess that hiding instructions at weird alignments is a valid obfuscation technique - i.e. it's not just aesthetics/performance.
    - LMYahooTFY 5y ago
      Are there any easily digestible resources you could point to for getting a better grasp of this?
      - mhh__ 5y ago
        What in particular?
      - fragmede 5y ago
        https://microcorruption.com/login https://microcorruption.com/login might be one place to start, but it's got a slightly different focus, but if you broadly want to learn lower-level stuff it's a place to start.
paulmd 5y ago
We'll get a live test of this very soon - Zen4 is going to be going head-to-head against Apple A16 (Apple's next core architecture) on TSMC N5P next year. Does anyone expect x86 to close a factor-of-6 perf/watt difference? (from Anandtech's M1 Max preview) A factor-of-2-to-3 IPC difference? And that's just A15, not against the next-gen A16. Node makes a big difference, it doesn't close up a factor-of-3 IPC gap in a single node though, that's facially ridiculous. Name a full-node shrink+architectural step that has tripled IPC in the last 10 years. Now name one that has done it while cutting power in 1/6th. At that point we will see the goalposts shift again and it will be "well, x86 could do it if they wanted but Apple is just more willing to spend more transistors..." Fact of the matter is the x86 makes it very difficult to spend those transistors efficiently - otherwise it already would have been done. If it was such an obvious gain to just spend those extra transistors, then surely AMD would have done it, if nobody else. Everyone acknowledges x86 has some problems, but the other thing is that they've already mostly played their hand trying to fix those problems, the known solutions like instruction cache have mostly been exhausted at this point. The idea that AMD and Apple can just triple IPC at a whim but they've chosen not to do so for some reason, is facially ridiculous. I know what Jim Keller said but the math just doesn't add up on it for me. OK, full node shrink, great, even if that doubles your transistor count at iso-power, or even doubles it at a little less power, that doesn't double your IPC let alone triple it, and it doesn't close a factor-of-6 perf/watt gap.
- TomVDB 5y ago
  > Does anyone expect x86 to close a factor-of-6 perf/watt difference? The one number that surprised me in this review was that the perf/W of Threadripper for the rendering phase: it is very close to the M1 Max. I understand that the numbers are not apples to apples because of the total laptop vs CPU-only comparison, but the power consumption of the Threadripper CPU itself is very high and probably takes the lion's share of the overall power consumption. And that's for a previous generation Threadripper.
  - paulmd 5y ago
    task energy comparisons are usually won by the processor that gets it done fastest in absolute terms: because of the overhead of the rest of the system, it takes a really big perf/watt win to come out ahead of the system that maybe isn't as efficient in actual watts but gets it done in half the time, because you pay the system overhead for a shorter period of time. it's also a 128-thread processor being put against a 8+2 thread processor, and that's the closest thing to something that will outweigh Apple's IPC advantage here: super wide processor clocked super slow, and unlike the more realistic comparisons (laptop processors, etc) the Epyc has deployed over four times as much silicon just to match the M1. This is the absolute best-case scenario for x86 - they get six times as much silicon and 16 times as many threads and all they can do is match it. Do the comparison again against the Mac Pro 40-core chip when it comes out and you'll see A15 pull ahead again.
urthor 5y ago
Most of the chip-heads' deep hatred for x86 comes from the number of pain-points for dealing with its ISA. In terms of actual raw performance the instruction set is extremely secondary to about 10 other architectural choices. The reason Apple is getting such performance is because it's caught up with all the cutting edge techniques Intel and AMD use, and a few more, and implemented them inside its core architecture.
MobiusHorizons 5y ago
The two primary mechanisms I am aware of are drastically simpler instruction decoding and lack of backwards compatibility. Both of these save on power and area, allowing those budgets to be spent elsewhere. Often times on wider instruction decode, extra execution units, better branch prediction, etc. These budgets are much tighter on a mobile chip, but are still relevant on desktop design.

entee 5y ago

Not a chiphead, but saw this in the article that might be a reason ARM is better for this kind of thing: "The theory goes that arm64’s fixed instruction length and relatively simple instructions make implementing extremely wide decoding and execution far more practical for Apple, compared with what Intel and AMD have to do in order to decode x86-64’s variable length, often complex compound instructions." Not sure it's true, not an expert. But it doesn't sound wrong!

throwawaylinux 5y ago
The fixed width decoders have always been a commonly cited advantage of fixed width, and to some degree it must be true. But this is not a recent thing, the "common wisdom" about instruction format not mattering too much still very much applies here. Pre-decode lengths or stop-bits and more recently micro-op caches have been techniques that x86 has used to mitigate this and improve front end widths, for example. People like Jim Keller (who has actually worked and lead teams implementing these very processors at Apple, Intel, and AMD!) basically say as much (while acknowledging decode is a little harder, in the large scheme of things on modern large cores it's not such a big deal): https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/ https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-... Andy Glew, one of the architects for Intel's first out of order x86 core (P6) among other things, is another who has said similar. https://groups.google.com/g/comp.arch/c/elke1FHfYr0/m/SwW9NT1x2gMJ https://groups.google.com/g/comp.arch/c/elke1FHfYr0/m/SwW9NT...
- mhh__ 5y ago
  > X86 tax might be 5% A consistent 5% win is pretty huge for certain industries.
  - throwawaylinux 5y ago
    > A consistent 5% win is pretty huge for certain industries. Are you referring to Andy Glew's thread? He said perhaps 5%, but he also went on to say probably less than 5% for basically the lowest-end out of order processor that was fielded (A-9), not what you would call a high performance core (even then 10 years ago). On today's high performance cores? Not sure, extrapolating naively from what he said would suggest even less. Which is backed up by what Jim Keller says later. So << 5%, which is significantly less than process node generational increases. I'm not saying ARM won't leapfrog x86, I'm just asking what the basis is for that belief, and what those who believe it think they know that the likes of Jim Keller does not. If it's an argument about something other than details of instruction set implementation (e.g., economics or process technology) then that would be something. That is exactly how Intel beat the old minicomputer companies' RISCs despite having "x86 tax", is that they got revenues to fund better process technology and bigger logic design teams. Although that's harder to apply to Apple vs AMD/Intel because x86 PC and server units and revenues are also huge, and TSMC gives at least AMD a common manufacturing base even if Apple is able to pay for some advantage there.
  - TomVDB 5y ago
    Yes, but people aren't impressed by the M1 chips because of 5% KPI differences.

ant6n 5y ago

Mmh, perhaps the fixed width instruction set makes ultra wide decoders easier.

dnautics 5y ago
I am not a chiphead either (but I used to live with some) I think easier decoders => shorter pipeline, less silicon footprint for decode, possibly more silicon for reordering logic, less dark silicon, etc. To be fair the chipheads I lived with were gaga about VLIW, so there was certainly a bias there.
- paulmd 5y ago
  I mean, VLIW is fantastic as long as you have very predictable workloads with high parallelism and little branching that are very easily statically scheduled. If you want to design a DSP or something, where you know it’ll be 100% saturated all the time with an absolutely predictable workload, it’s extremely efficient. Same for AMD Terascale GPUs back in the days before async compute and other GPGPU style tasks took over.

mhh__ 5y ago

Two thoughts: 1. The instruction set isn't so much a performance thing as much as a thing that bites you with power usage (you need to have a big fat decoder on all the time in the worst case). The widest X86's can only dispatch 75% of the instruction per cycle but X86 instructions can do more, so you'd have to check a specific benchmark. 2. I want X86 to die more because it's fucking ugly than performance as per se. ARM is not a simple ISA, so although you won't be writing a disassembler in 10 minutes like RISC-V, aarch64 is still much less insane than X86 with all the extensions.

Osiris 5y ago
The vast majority of developers will never even see assembly for x86 or ARM. Compiler developers and those need to hand optimize code may care but for everyone else it's a black box.
- mhh__ 5y ago
  Sure but I am part of that latter category. The unwashed masses don't have to care and won't actually use the performance, I'm not that bothered whether they care or not, although it's worth saying that X86 is such a mess that hiding instructions at weird alignments is a valid obfuscation technique - i.e. it's not just aesthetics/performance.
  - LMYahooTFY 5y ago
    Are there any easily digestible resources you could point to for getting a better grasp of this?
    - mhh__ 5y ago
      What in particular?
    - fragmede 5y ago
      https://microcorruption.com/login https://microcorruption.com/login might be one place to start, but it's got a slightly different focus, but if you broadly want to learn lower-level stuff it's a place to start.

paulmd 5y ago

We'll get a live test of this very soon - Zen4 is going to be going head-to-head against Apple A16 (Apple's next core architecture) on TSMC N5P next year. Does anyone expect x86 to close a factor-of-6 perf/watt difference? (from Anandtech's M1 Max preview) A factor-of-2-to-3 IPC difference? And that's just A15, not against the next-gen A16. Node makes a big difference, it doesn't close up a factor-of-3 IPC gap in a single node though, that's facially ridiculous. Name a full-node shrink+architectural step that has tripled IPC in the last 10 years. Now name one that has done it while cutting power in 1/6th. At that point we will see the goalposts shift again and it will be "well, x86 could do it if they wanted but Apple is just more willing to spend more transistors..." Fact of the matter is the x86 makes it very difficult to spend those transistors efficiently - otherwise it already would have been done. If it was such an obvious gain to just spend those extra transistors, then surely AMD would have done it, if nobody else. Everyone acknowledges x86 has some problems, but the other thing is that they've already mostly played their hand trying to fix those problems, the known solutions like instruction cache have mostly been exhausted at this point. The idea that AMD and Apple can just triple IPC at a whim but they've chosen not to do so for some reason, is facially ridiculous. I know what Jim Keller said but the math just doesn't add up on it for me. OK, full node shrink, great, even if that doubles your transistor count at iso-power, or even doubles it at a little less power, that doesn't double your IPC let alone triple it, and it doesn't close a factor-of-6 perf/watt gap.

TomVDB 5y ago
> Does anyone expect x86 to close a factor-of-6 perf/watt difference? The one number that surprised me in this review was that the perf/W of Threadripper for the rendering phase: it is very close to the M1 Max. I understand that the numbers are not apples to apples because of the total laptop vs CPU-only comparison, but the power consumption of the Threadripper CPU itself is very high and probably takes the lion's share of the overall power consumption. And that's for a previous generation Threadripper.
- paulmd 5y ago
  task energy comparisons are usually won by the processor that gets it done fastest in absolute terms: because of the overhead of the rest of the system, it takes a really big perf/watt win to come out ahead of the system that maybe isn't as efficient in actual watts but gets it done in half the time, because you pay the system overhead for a shorter period of time. it's also a 128-thread processor being put against a 8+2 thread processor, and that's the closest thing to something that will outweigh Apple's IPC advantage here: super wide processor clocked super slow, and unlike the more realistic comparisons (laptop processors, etc) the Epyc has deployed over four times as much silicon just to match the M1. This is the absolute best-case scenario for x86 - they get six times as much silicon and 16 times as many threads and all they can do is match it. Do the comparison again against the Mac Pro 40-core chip when it comes out and you'll see A15 pull ahead again.

urthor 5y ago

Most of the chip-heads' deep hatred for x86 comes from the number of pain-points for dealing with its ISA. In terms of actual raw performance the instruction set is extremely secondary to about 10 other architectural choices. The reason Apple is getting such performance is because it's caught up with all the cutting edge techniques Intel and AMD use, and a few more, and implemented them inside its core architecture.

MobiusHorizons 5y ago

The two primary mechanisms I am aware of are drastically simpler instruction decoding and lack of backwards compatibility. Both of these save on power and area, allowing those budgets to be spent elsewhere. Often times on wider instruction decode, extra execution units, better branch prediction, etc. These budgets are much tighter on a mobile chip, but are still relevant on desktop design.