4 ms·

I often see sentiment that x86 architecture itself is fundamentally a bottleneck, compared to ARM/RISC, when it comes to efficiency and performance per watt. Do

I often see sentiment that x86 architecture itself is fundamentally a bottleneck, compared to ARM/RISC, when it comes to efficiency and performance per watt. Does someone with the right expertise have insight to share on this? I'm curious what the factors are here. I would imagine that a factor is that most ARM implementations we see (like from Qualcomm, Nvidia, and Apple) are full-on SoCs which will naturally have efficiency benefits. But I'd love to learn more about this before "taking sides" and declaring that so-and-so architecture is the future, or whatever.

Sparkyte 3y ago
X86 and ARM are practically the same these days in performance. Let me explain RISC vs CISC, RISC is Reduced Instruction Set Computer and CISC is Complex Instruction Set Computer. The base component instruction sets of x86 are CISC. The base component instruction sets of ARM are RISC. When technology evolves and newer instruction sets are required to handle those tasks they can often become more complex and so today with the variety of instruction sets on both x86 and ARM they are closer to each other more than ever. Still different. Now going to the differences between ARM and x86 where it matters. ARM has the lowest power draw to performance ratio but it's need for power skyrockets as it approaches more complicated tasks. x86 starts higher in power draw but its performance is pretty maintained under all workloads. Neither are wrong, just it depends what you're planning to do. x86 is probably the best architecture for the general user, but ARM is great in a phone if everything stays relatively simple. Notice how some phones with 4000 mAh battery will be dead in 30mins while playing a game which the Steam Deck can handle for maybe 1.5 hours of gameplay? However if I wanted something to stay on all day to receive text notifications and pretty much be idle in my pocket, I'd want an ARM processor. I think the real reason Apple went ARM is that after studying the life habits of their customers they realized most of their laptop users fold sleep their devices like a phone without ever really charging them. At least the majority, when working in a Mac Shop, the term used for a mac only software development team, the constant amount of fold close open recharge would've been better on an ARM processor. Someone at work even asked if they could just code on their Samsung phone because it got better battery life than the old Intel Macs.
- api 3y ago
  Isn't there a problem with the parallel decoding of x86 streams due to all the different instruction lengths? I've read that going much beyond 4 parallel decodes in x86 gets increasingly hard, requiring expensive combinatorial logic. Meanwhile ARM instruction decoding can trivially be parallelized as much as you want. Other than this I am not familiar with any other fundamental limits to making x86 as efficient as ARM or ARM as fast as x86.
  - Sparkyte 3y ago
    Sorta, this is actually a CPU cache thing, ARM can do it efficiently not needing a lot of CPU cache to handle parrellel decoding. x86 requires more cache to do so. However more cache has its benefits not just in this task. Cache is also getting cheaper.
    - api 3y ago
      That still implies both more logic and more "hot" silicon, so decoding is higher overhead. I recall reading about creating a subset of x86_64 that would be faster to decode, but this would effectively be a different architecture so at that point you might as well go to ARM64 or RISC-V. I do know that if the instruction set decodes efficiently and is compact (to reduce memory bandwidth) it really doesn't matter much beyond that.
      - Sparkyte 3y ago
        It doesn't matter though technology is ever evolving. More cache will eventually be the norm on chips. Wide lanes for threads too. M1 has four times the bit width of an AMD Ryzen processor. Supposedly next generation of Ryzen processors the Zen 5 will have a wider bit width.
      - snvzz 3y ago
        >I do know that if the instruction set decodes efficiently and is compact (to reduce memory bandwidth) it really doesn't matter much beyond that. RISC-V is also simple, and that's relative to ARM64, nevermind x86. I.e. it is achieving highly competitive code density and instruction count despite being simpler.

Sparkyte 3y ago

X86 and ARM are practically the same these days in performance. Let me explain RISC vs CISC, RISC is Reduced Instruction Set Computer and CISC is Complex Instruction Set Computer. The base component instruction sets of x86 are CISC. The base component instruction sets of ARM are RISC. When technology evolves and newer instruction sets are required to handle those tasks they can often become more complex and so today with the variety of instruction sets on both x86 and ARM they are closer to each other more than ever. Still different. Now going to the differences between ARM and x86 where it matters. ARM has the lowest power draw to performance ratio but it's need for power skyrockets as it approaches more complicated tasks. x86 starts higher in power draw but its performance is pretty maintained under all workloads. Neither are wrong, just it depends what you're planning to do. x86 is probably the best architecture for the general user, but ARM is great in a phone if everything stays relatively simple. Notice how some phones with 4000 mAh battery will be dead in 30mins while playing a game which the Steam Deck can handle for maybe 1.5 hours of gameplay? However if I wanted something to stay on all day to receive text notifications and pretty much be idle in my pocket, I'd want an ARM processor. I think the real reason Apple went ARM is that after studying the life habits of their customers they realized most of their laptop users fold sleep their devices like a phone without ever really charging them. At least the majority, when working in a Mac Shop, the term used for a mac only software development team, the constant amount of fold close open recharge would've been better on an ARM processor. Someone at work even asked if they could just code on their Samsung phone because it got better battery life than the old Intel Macs.

api 3y ago
Isn't there a problem with the parallel decoding of x86 streams due to all the different instruction lengths? I've read that going much beyond 4 parallel decodes in x86 gets increasingly hard, requiring expensive combinatorial logic. Meanwhile ARM instruction decoding can trivially be parallelized as much as you want. Other than this I am not familiar with any other fundamental limits to making x86 as efficient as ARM or ARM as fast as x86.
- Sparkyte 3y ago
  Sorta, this is actually a CPU cache thing, ARM can do it efficiently not needing a lot of CPU cache to handle parrellel decoding. x86 requires more cache to do so. However more cache has its benefits not just in this task. Cache is also getting cheaper.
  - api 3y ago
    That still implies both more logic and more "hot" silicon, so decoding is higher overhead. I recall reading about creating a subset of x86_64 that would be faster to decode, but this would effectively be a different architecture so at that point you might as well go to ARM64 or RISC-V. I do know that if the instruction set decodes efficiently and is compact (to reduce memory bandwidth) it really doesn't matter much beyond that.
    - Sparkyte 3y ago
      It doesn't matter though technology is ever evolving. More cache will eventually be the norm on chips. Wide lanes for threads too. M1 has four times the bit width of an AMD Ryzen processor. Supposedly next generation of Ryzen processors the Zen 5 will have a wider bit width.
    - snvzz 3y ago
      >I do know that if the instruction set decodes efficiently and is compact (to reduce memory bandwidth) it really doesn't matter much beyond that. RISC-V is also simple, and that's relative to ARM64, nevermind x86. I.e. it is achieving highly competitive code density and instruction count despite being simpler.