7 ms·

The next decade is ARM's for the taking, but if Intel and AMD can make good cores then it's not anywhere close to slam dunk. One of the reasons why M1 is good

by mhh__ 6y ago

The next decade is ARM's for the taking, but if Intel and AMD can make good cores then it's not anywhere close to slam dunk. One of the reasons why M1 is good is pure and simple that it has a pretty enormous transistor budget, not solely because it's ARM.

tambourine_man 6y ago
>…is pure and simple that it has a pretty enormous transistor budget There's a lot of brute force, yes, but it's not the only reason. There are lots of smart design decisions as well.
- mhh__ 6y ago
  "One of the reasons" I did say.
  - tambourine_man 6y ago
    True, I misread it.
- amelius 6y ago
  Yes, but those decisions optimize for the single user laptop case, not for e.g. servers.
api 6y ago
Being ARM has something to do with it. The x86 instruction decoder may be only about ~5% of the die, but it's 5% of the die that has to run all the time. Think about how warm your CPU gets when you run e.g. heavy FPU loads and then imagine that's happening all the time. You can see the power difference right there. It's also very hard to achieve more than 4X parallelism (though I think Ice Lake got 6X at some additional cost) in decode, making instruction level parallelism harder. X86's hack to get around this is SMT/hyperthreading to keep the core fed with 2X instruction streams, but that adds a lot more complexity and is a security minefield. Last but not least: ARM's looser default memory model allows for more read/write reordering and a simpler cache. ARM has a distinct simplicity and low-overhead advantage over X86/X64.
- mhh__ 6y ago
  This is why I said it's ARM's for the taking. I'm not familiar with how ARM's memory model effects the cache design - Source?
- NortySpock 6y ago
  > x86 instruction decoder may be only about ~5% of the die What percent of the die is an ARM instruction decoder?
  - duskwuff 6y ago
    Much less. x86 instruction decoding is complicated by the fact that instructions are variable-width and are byte-aligned (i.e. any instruction can begin at any address). This makes decoding more than one instruction per clock cycle complicated -- I believe the silicon has to try decoding instructions at every possible offset within the decode buffer, then mask out the instructions which are actually inside another instruction. ARM A32/A64 instruction decoding is dramatically simpler -- all instructions are 32 bits wide and word-aligned, so decoding them in parallel is trivial. T32 ("Thumb") is a bit more complex, but still easier than x86.
    - monocasa 6y ago
      I totally agree with the core of your argument (aarch64 decoding is inherently simpler and more power efficient than x86), but I'll throw out there that it's not quite as bad as you say on x86 as there's some nonobvious efficiencies (I've been writing a parallel x86 decoder). What nearly everyone uses is a 16 byte buffer aligned to the program counter being fed into the first stage decode. This first stage, yes has to look at each byte offset as if it could be a new instruction, but doesn't have to do full decode. It only finds instruction length information. From there you feed this length information in and do full decode on the byte offsets that represent actual instruction boundaries. That's how you end up with x86 cores with '4 wide decode' despite needing to initially look at each byte. Now for the efficiencies. Each length decoder for each byte offset isn't symmetric. Only the length decoder at offset 0 in the buffer has to handle everything, and the other length decoders can simply flag "I can't handle this", and the buffer won't be shifted down past where they were on the next cycle and the byte 0 decoder can fix up any goofiness. Because of this, they can * be stripped out of instructions that aren't really used much anymore if that helps them * can be stripped of weird cases like handling crazy usages of prefix bytes * don't have to handle instructions bigger than their portion of the decode buffer. For instance a length decoder starting at byte 12 can't handle more than a 4 byte instruction anyway, so that can simplify it's logic considerably. That means that the simpler length decoders end up feeding into the higher stack up full decoder selection, so some of the overhead cancels out in a nice way. On top of that, I think that 5% includes pieces like the microcode ROMs. Modern ARM cores almost certainly have (albeit much smaller) microcode ROMs as well to handle the more complex state transitions. Once again, totally agreed with your main point, but it's closer than what the general public consensus says.
jayd16 6y ago
Another reason is the something like 150% memory bandwidth and I'm sure there are other simple wins along those lines. The M1 isn't necessarily a win for Arm in general. Other manufacturers weren't competing before and its yet to be seen if they will.
- mhh__ 6y ago
  It's the memory stupid!
  - to11mtm 6y ago
    Specifically, the memory -latency-. By going on-package there's almost certainly latency advantages in addition to the much-vaunted bandwidth gains. That's going to pan out to better perf, and likely better power usage as well.
    - mhh__ 6y ago
      Is M1 on package? Or is it on-die that people keep getting wrong
      - als0 6y ago
        The memory and CPU are on the same package, not die.
    - wmf 6y ago
      M1 memory latency isn't noticeably lower than x86.
- NathanielK 6y ago
  150% compared to what?
  - jayd16 6y ago
    The latest i9 and the latest Ryzen 9, ie the competition.
ravi-delia 6y ago
I've seen things like this a lot, and it's a bit confusing. If parts of the M1's performance are due to throwing compute at the problem, why hasn't Intel been doing that for years? What about ARM, or the M1, allowed this to happen?
- dpatterbee 6y ago
  Buying the majority of TSMC's 5nm process output helped. It's a combination of good engineering, the most advanced process, and intel shitting themselves I would say.
- NathanielK 6y ago
  Intel has. Many M1 design choices are fairly typical for desktop x86 chips, but unheard of with ARM. For example, the M1 has 128 bit wide memory. This has been standard for decades on the desktop(dual channel), but unheard of in cellphones. The M1 also has similar amounts of cache to the new AMD and Intel chips, but thats several times more than the latest snapdragon. Qualcomm also doesn't just design for the latest node. Most of their volume is on cheaper, less dense nodes.
  - ravi-delia 6y ago
    So from this (and some other places), it kind of seems like ARM has been competitive for a long time, but for power and temperature saving its been fighting with one hand behind its back. That's intriguing in its own right, but I'm still confused as to what the actual differences are. Like the M1 runs as fast as current gen x86 processors, while running cooler. How?
    - NathanielK 6y ago
      > Like the M1 runs as fast as current gen x86 processors, while running cooler. How? The M1 is one "node" ahead. Apple forked out the cash to get all their chips on TSMC's 5nm process. This is about 2 years of advancement over the 7nm process AMD pays TSMC for. Intel's latest 10nm node is similarly behind TSMC 5nm. Semiconductors are tricky. Small performance gains take large increases in power. If you play with overclocking, you'll learn power increases quadratically or even cubically with clocks. The mere "2nm" shrink may seem inconsequential, but for these iso-perfomance comparisons(performance@constant-thermals), it is key. All this to say, you get what you pay for. Chips can get the same performance on TSMC's 5nm node while using 70% of the power as chips on the 7nm node.[1] Compared to TSMC's 10nm (similar to Intel's popular 14nm still in production), 5nm chips can be expected to use ~45% of the power. Hopefully that shed some light on the M1's biggest advantage for you. [1] https://images.anandtech.com/doci/15219/wikichip_tsmc_logic_node_q2_2019.png https://images.anandtech.com/doci/15219/wikichip_tsmc_logic_...
phendrenad2 6y ago
It really comes down to how well they can emulate X86. People aren't going to give up access to 3 decades of Windows software.
- pjerem 6y ago
  I'm sure ARM already took over x86 if you have a wider definition of personal computers. And a lot of people already gave up access to 3 decades of Windows software by using their phone or tablet as their main device. Plus, most of the last decade software is software that runs on some sort of VM or another (be it JVM, CLR, a Javascript engine or even LLVM). Soon (in years), x86 will only be needed by professionals that are tied to really old software. And those particular needs will probably be satisfied by decent emulation.
  - kllrnohj 6y ago
    > Soon (in years), x86 will only be needed by professionals that are tied to really old software. There's also that PC & console gaming markets, which are not small and have not made any movements of any kind towards ARM so far.
    - _ph_ 6y ago
      Except of course the Nintendo Switch and the handheld devices like the 3DS. They are all ARM-based.
  - astrange 6y ago
    LLVM isn't actually a VM, it's a compiler IR with good marketing. LLVM programs are architecture specific, although of course ARM64 and x86-64 are pretty similar.

by mhh__ 6y ago

tambourine_man 6y ago

>…is pure and simple that it has a pretty enormous transistor budget There's a lot of brute force, yes, but it's not the only reason. There are lots of smart design decisions as well.

mhh__ 6y ago
"One of the reasons" I did say.
- tambourine_man 6y ago
  True, I misread it.
amelius 6y ago
Yes, but those decisions optimize for the single user laptop case, not for e.g. servers.

api 6y ago

Being ARM has something to do with it. The x86 instruction decoder may be only about ~5% of the die, but it's 5% of the die that has to run all the time. Think about how warm your CPU gets when you run e.g. heavy FPU loads and then imagine that's happening all the time. You can see the power difference right there. It's also very hard to achieve more than 4X parallelism (though I think Ice Lake got 6X at some additional cost) in decode, making instruction level parallelism harder. X86's hack to get around this is SMT/hyperthreading to keep the core fed with 2X instruction streams, but that adds a lot more complexity and is a security minefield. Last but not least: ARM's looser default memory model allows for more read/write reordering and a simpler cache. ARM has a distinct simplicity and low-overhead advantage over X86/X64.

mhh__ 6y ago
This is why I said it's ARM's for the taking. I'm not familiar with how ARM's memory model effects the cache design - Source?
NortySpock 6y ago
> x86 instruction decoder may be only about ~5% of the die What percent of the die is an ARM instruction decoder?
- duskwuff 6y ago
  Much less. x86 instruction decoding is complicated by the fact that instructions are variable-width and are byte-aligned (i.e. any instruction can begin at any address). This makes decoding more than one instruction per clock cycle complicated -- I believe the silicon has to try decoding instructions at every possible offset within the decode buffer, then mask out the instructions which are actually inside another instruction. ARM A32/A64 instruction decoding is dramatically simpler -- all instructions are 32 bits wide and word-aligned, so decoding them in parallel is trivial. T32 ("Thumb") is a bit more complex, but still easier than x86.
  - monocasa 6y ago
    I totally agree with the core of your argument (aarch64 decoding is inherently simpler and more power efficient than x86), but I'll throw out there that it's not quite as bad as you say on x86 as there's some nonobvious efficiencies (I've been writing a parallel x86 decoder). What nearly everyone uses is a 16 byte buffer aligned to the program counter being fed into the first stage decode. This first stage, yes has to look at each byte offset as if it could be a new instruction, but doesn't have to do full decode. It only finds instruction length information. From there you feed this length information in and do full decode on the byte offsets that represent actual instruction boundaries. That's how you end up with x86 cores with '4 wide decode' despite needing to initially look at each byte. Now for the efficiencies. Each length decoder for each byte offset isn't symmetric. Only the length decoder at offset 0 in the buffer has to handle everything, and the other length decoders can simply flag "I can't handle this", and the buffer won't be shifted down past where they were on the next cycle and the byte 0 decoder can fix up any goofiness. Because of this, they can * be stripped out of instructions that aren't really used much anymore if that helps them * can be stripped of weird cases like handling crazy usages of prefix bytes * don't have to handle instructions bigger than their portion of the decode buffer. For instance a length decoder starting at byte 12 can't handle more than a 4 byte instruction anyway, so that can simplify it's logic considerably. That means that the simpler length decoders end up feeding into the higher stack up full decoder selection, so some of the overhead cancels out in a nice way. On top of that, I think that 5% includes pieces like the microcode ROMs. Modern ARM cores almost certainly have (albeit much smaller) microcode ROMs as well to handle the more complex state transitions. Once again, totally agreed with your main point, but it's closer than what the general public consensus says.

jayd16 6y ago

Another reason is the something like 150% memory bandwidth and I'm sure there are other simple wins along those lines. The M1 isn't necessarily a win for Arm in general. Other manufacturers weren't competing before and its yet to be seen if they will.

mhh__ 6y ago
It's the memory stupid!
- to11mtm 6y ago
  Specifically, the memory -latency-. By going on-package there's almost certainly latency advantages in addition to the much-vaunted bandwidth gains. That's going to pan out to better perf, and likely better power usage as well.
  - mhh__ 6y ago
    Is M1 on package? Or is it on-die that people keep getting wrong
    - als0 6y ago
      The memory and CPU are on the same package, not die.
  - wmf 6y ago
    M1 memory latency isn't noticeably lower than x86.
NathanielK 6y ago
150% compared to what?
- jayd16 6y ago
  The latest i9 and the latest Ryzen 9, ie the competition.

ravi-delia 6y ago

I've seen things like this a lot, and it's a bit confusing. If parts of the M1's performance are due to throwing compute at the problem, why hasn't Intel been doing that for years? What about ARM, or the M1, allowed this to happen?

dpatterbee 6y ago
Buying the majority of TSMC's 5nm process output helped. It's a combination of good engineering, the most advanced process, and intel shitting themselves I would say.
NathanielK 6y ago
Intel has. Many M1 design choices are fairly typical for desktop x86 chips, but unheard of with ARM. For example, the M1 has 128 bit wide memory. This has been standard for decades on the desktop(dual channel), but unheard of in cellphones. The M1 also has similar amounts of cache to the new AMD and Intel chips, but thats several times more than the latest snapdragon. Qualcomm also doesn't just design for the latest node. Most of their volume is on cheaper, less dense nodes.
- ravi-delia 6y ago
  So from this (and some other places), it kind of seems like ARM has been competitive for a long time, but for power and temperature saving its been fighting with one hand behind its back. That's intriguing in its own right, but I'm still confused as to what the actual differences are. Like the M1 runs as fast as current gen x86 processors, while running cooler. How?
  - NathanielK 6y ago
    > Like the M1 runs as fast as current gen x86 processors, while running cooler. How? The M1 is one "node" ahead. Apple forked out the cash to get all their chips on TSMC's 5nm process. This is about 2 years of advancement over the 7nm process AMD pays TSMC for. Intel's latest 10nm node is similarly behind TSMC 5nm. Semiconductors are tricky. Small performance gains take large increases in power. If you play with overclocking, you'll learn power increases quadratically or even cubically with clocks. The mere "2nm" shrink may seem inconsequential, but for these iso-perfomance comparisons(performance@constant-thermals), it is key. All this to say, you get what you pay for. Chips can get the same performance on TSMC's 5nm node while using 70% of the power as chips on the 7nm node.[1] Compared to TSMC's 10nm (similar to Intel's popular 14nm still in production), 5nm chips can be expected to use ~45% of the power. Hopefully that shed some light on the M1's biggest advantage for you. [1] https://images.anandtech.com/doci/15219/wikichip_tsmc_logic_node_q2_2019.png https://images.anandtech.com/doci/15219/wikichip_tsmc_logic_...

phendrenad2 6y ago

It really comes down to how well they can emulate X86. People aren't going to give up access to 3 decades of Windows software.

pjerem 6y ago
I'm sure ARM already took over x86 if you have a wider definition of personal computers. And a lot of people already gave up access to 3 decades of Windows software by using their phone or tablet as their main device. Plus, most of the last decade software is software that runs on some sort of VM or another (be it JVM, CLR, a Javascript engine or even LLVM). Soon (in years), x86 will only be needed by professionals that are tied to really old software. And those particular needs will probably be satisfied by decent emulation.
- kllrnohj 6y ago
  > Soon (in years), x86 will only be needed by professionals that are tied to really old software. There's also that PC & console gaming markets, which are not small and have not made any movements of any kind towards ARM so far.
  - _ph_ 6y ago
    Except of course the Nintendo Switch and the handheld devices like the 3DS. They are all ARM-based.
- astrange 6y ago
  LLVM isn't actually a VM, it's a compiler IR with good marketing. LLVM programs are architecture specific, although of course ARM64 and x86-64 are pretty similar.