4 ms·

Can anyone explain in a few sentences why the ARM architecture seems to outperform traditional CPUs so much? What fundamentally prevents Intel from building som

by goerz 6y ago

Can anyone explain in a few sentences why the ARM architecture seems to outperform traditional CPUs so much? What fundamentally prevents Intel from building something comparable?

dahfizz 6y ago
It is a Reduced Instruction Set computer. It's a greatly simplified design. The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. You can read more about how microcode and micro ops work here: https://en.m.wikipedia.org/wiki/Intel_Microcode https://en.m.wikipedia.org/wiki/Intel_Microcode
- umanwizard 6y ago
  I don't think that's the entire reason. Most of the common x86 instructions occurring in a normal program can be decoded to a few uops in a straightforward way, and since Sandy Bridge the decoded uops are cached anyway. So this would only be a significant bottleneck for hot loops that are large enough that they don't fit in the uop cache. It's definitely a real issue but it seems wrong to pin all or even most of Intel's stagnation on that.
- cesarb 6y ago
  > The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. > Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. This is a sadly prevalent misconception. There is no "compiler in hardware". There are two kinds of instructions; the simpler ones (which are the most common) are expanded directly into a fixed sequence of micro-ops, while the more complicated ones act like a subroutine call to the microcode. The closest software analogue would be a macro assembler, not a compiler. AFAIK, the extra complexity for efficiently decoding x86 instructions comes mostly from their variable length without an explicit length indication, and from the variable number of prefixes which can change the interpretation of the following byte, which makes decoding an instruction a serial task. IIRC, both Intel and AMD have a couple of tricks to reduce the impact this has on both power and performance: caching the already decoded micro-ops, and storing the instruction boundaries in the L1 instruction cache.
- jeffbee 6y ago
  So, that's the freshman-year CS view of the topic, but back here in reality land the "complicated" x86 instruction format has pretty much destroyed all others and none of the supposed advantages of RISC actually exist. Remember that the whole point of RISC is that the CPUs would supposedly run faster. That hasn't happened. There are no RISC CPUs running faster than state-of-the-art x86 CPUs. POWER8 comes closest, but does not exceed. The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. This is a form of compression. Having a compressed program image turns out to be a massive advantage. RISC proponents thought that x86 was so complicated they could beat Intel with their simple instruction decoders. That almost, but not really, made sense in 1990 but since then has made increasingly less sense, until today where the amount of sense this makes has hit zero. The x86 instruction decoder is a very small part of the floor plan of a modern CPU and every time they rev the microarchitecture it gets smaller. The number of transistors needed to decode the VEX prefix is like a speck of sand on the beach of a 512x512-bit multiplier.
  - acidbaseextract 6y ago
    > The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. The RISC philosophy wasn't a mistake. Our architectures have just become more sophisticated so that we don't have to make a binary choice. The hybrid is good. The internal uops get the pipelining advantages of RISC, while we get the encoding compression of a CISC instruction set.
- gandalfgeek 6y ago
  If you look at the latest ARM instruction sets they are not really "RISC". Sure, they're much saner than than the crazy legacy instructions that x86 carries, but still nowhere near a "real RISC" ISA as espoused by Hennessy and Patterson, the hallmarks of which are simple, orthogonal, atomic instructions, and a small number of them. Currently that is most closely embodied by RISC-V. If you look at how you can get computing gains going forward after the end of Moore's law, of course the glib answer is "parallelize across more cores!" but the more interesting path is to notice that behemoth single cores like x86 spend a ton of silicon area trying to optimize straight-line execution with things like speculative execution. If you saved all that silicon area, making each single core slower but smaller, but packed more cores on the die as a result, you would most likely come out faster. [1] [1]: https://science.sciencemag.org/content/368/6495/eaam9744/tab-pdf https://science.sciencemag.org/content/368/6495/eaam9744/tab...
webaholic 6y ago
There is no inherent advantage to the ARM architecture other than it being designed recently (64-bit ARM is less than a decade old) whereas x86 has a lot of baggage it has to carry. There is no proof that these outperform traditional CPUs at all. That is the reason you don't see them being used anywhere other than niche use cases or for cost reasons.
- lowbloodsugar 6y ago
  >That is the reason you don't see them being used anywhere other than niche use cases or for cost reasons. By 2017 there were three times as many smartphones than PCs, all running ARM chips. The top four supercomputers all use RISC, and the fastest uses ARM.
  - jfkebwjsbx 6y ago
    Phones are not built for performance, which is what was asked about. As for supercomputers, >90% of them are Intel/AMD.
    - lowbloodsugar 6y ago
      Phones are built for performance per watt. Phones are benchmarked. In the context of a discussion on Apple introducing ARM chips into the Macbook line, performance per watt is far more meaningful. For most users, battery life is the issue once minimum performance criteria have been met. Will there be Razor laptops that last less than an hour on battery that can beat them? Sure. Will there be people who complain that the Mac isn't fast enough when plugged in? Already happening: the recent Macbook Pros have had complaints about thermal throttling, that obviously slightly larger Dell with a decent fan doesn't have. But Apple will build performance laptops, using ARM chips, and they will be faster than the equivalent Intel Macbooks if only because they aren't throttled.
      - jfkebwjsbx 6y ago
        The context of the discussion is literally ARM scaling up to desktop performance. The person you replied to said: > There is no proof that these outperform traditional CPUs at all. To which you replied talking about embedded market share and supercomputer which have nothing to do with that. Since now you mention Apple and MacBooks, which haven't been even mentioned, I think you are answering to the wrong thread/post.

by goerz 6y ago

Can anyone explain in a few sentences why the ARM architecture seems to outperform traditional CPUs so much? What fundamentally prevents Intel from building something comparable?

dahfizz 6y ago

It is a Reduced Instruction Set computer. It's a greatly simplified design. The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. You can read more about how microcode and micro ops work here: https://en.m.wikipedia.org/wiki/Intel_Microcode https://en.m.wikipedia.org/wiki/Intel_Microcode

umanwizard 6y ago
I don't think that's the entire reason. Most of the common x86 instructions occurring in a normal program can be decoded to a few uops in a straightforward way, and since Sandy Bridge the decoded uops are cached anyway. So this would only be a significant bottleneck for hot loops that are large enough that they don't fit in the uop cache. It's definitely a real issue but it seems wrong to pin all or even most of Intel's stagnation on that.
cesarb 6y ago
> The x86_64 ISA is absolutely insane. The only way to implement it in hardware efficiently is to "compile" the super complicated instructions into micro-ops which can actually be decoded and executed on the CPU. > Said another way, Intel has to implement a compiler in hardware which compiles the machine code before it gets executed. The extra complexity means more power and less performance. This is a sadly prevalent misconception. There is no "compiler in hardware". There are two kinds of instructions; the simpler ones (which are the most common) are expanded directly into a fixed sequence of micro-ops, while the more complicated ones act like a subroutine call to the microcode. The closest software analogue would be a macro assembler, not a compiler. AFAIK, the extra complexity for efficiently decoding x86 instructions comes mostly from their variable length without an explicit length indication, and from the variable number of prefixes which can change the interpretation of the following byte, which makes decoding an instruction a serial task. IIRC, both Intel and AMD have a couple of tricks to reduce the impact this has on both power and performance: caching the already decoded micro-ops, and storing the instruction boundaries in the L1 instruction cache.
jeffbee 6y ago
So, that's the freshman-year CS view of the topic, but back here in reality land the "complicated" x86 instruction format has pretty much destroyed all others and none of the supposed advantages of RISC actually exist. Remember that the whole point of RISC is that the CPUs would supposedly run faster. That hasn't happened. There are no RISC CPUs running faster than state-of-the-art x86 CPUs. POWER8 comes closest, but does not exceed. The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. This is a form of compression. Having a compressed program image turns out to be a massive advantage. RISC proponents thought that x86 was so complicated they could beat Intel with their simple instruction decoders. That almost, but not really, made sense in 1990 but since then has made increasingly less sense, until today where the amount of sense this makes has hit zero. The x86 instruction decoder is a very small part of the floor plan of a modern CPU and every time they rev the microarchitecture it gets smaller. The number of transistors needed to decode the VEX prefix is like a speck of sand on the beach of a 512x512-bit multiplier.
- acidbaseextract 6y ago
  > The whole RISC philosophy was a huge mistake. Yes, x86 instructions do not map well to transistors, and they have to be unpacked into uops to be executed. The RISC philosophy wasn't a mistake. Our architectures have just become more sophisticated so that we don't have to make a binary choice. The hybrid is good. The internal uops get the pipelining advantages of RISC, while we get the encoding compression of a CISC instruction set.
gandalfgeek 6y ago
If you look at the latest ARM instruction sets they are not really "RISC". Sure, they're much saner than than the crazy legacy instructions that x86 carries, but still nowhere near a "real RISC" ISA as espoused by Hennessy and Patterson, the hallmarks of which are simple, orthogonal, atomic instructions, and a small number of them. Currently that is most closely embodied by RISC-V. If you look at how you can get computing gains going forward after the end of Moore's law, of course the glib answer is "parallelize across more cores!" but the more interesting path is to notice that behemoth single cores like x86 spend a ton of silicon area trying to optimize straight-line execution with things like speculative execution. If you saved all that silicon area, making each single core slower but smaller, but packed more cores on the die as a result, you would most likely come out faster. [1] [1]: https://science.sciencemag.org/content/368/6495/eaam9744/tab-pdf https://science.sciencemag.org/content/368/6495/eaam9744/tab...

webaholic 6y ago

There is no inherent advantage to the ARM architecture other than it being designed recently (64-bit ARM is less than a decade old) whereas x86 has a lot of baggage it has to carry. There is no proof that these outperform traditional CPUs at all. That is the reason you don't see them being used anywhere other than niche use cases or for cost reasons.

lowbloodsugar 6y ago
>That is the reason you don't see them being used anywhere other than niche use cases or for cost reasons. By 2017 there were three times as many smartphones than PCs, all running ARM chips. The top four supercomputers all use RISC, and the fastest uses ARM.
- jfkebwjsbx 6y ago
  Phones are not built for performance, which is what was asked about. As for supercomputers, >90% of them are Intel/AMD.
  - lowbloodsugar 6y ago
    Phones are built for performance per watt. Phones are benchmarked. In the context of a discussion on Apple introducing ARM chips into the Macbook line, performance per watt is far more meaningful. For most users, battery life is the issue once minimum performance criteria have been met. Will there be Razor laptops that last less than an hour on battery that can beat them? Sure. Will there be people who complain that the Mac isn't fast enough when plugged in? Already happening: the recent Macbook Pros have had complaints about thermal throttling, that obviously slightly larger Dell with a decent fan doesn't have. But Apple will build performance laptops, using ARM chips, and they will be faster than the equivalent Intel Macbooks if only because they aren't throttled.
    - jfkebwjsbx 6y ago
      The context of the discussion is literally ARM scaling up to desktop performance. The person you replied to said: > There is no proof that these outperform traditional CPUs at all. To which you replied talking about embedded market share and supercomputer which have nothing to do with that. Since now you mention Apple and MacBooks, which haven't been even mentioned, I think you are answering to the wrong thread/post.