7 ms·

Apple is competitive with Intel. Not ARM in a more general way. So I don't really see how Intel could magically produce a vastly better microarchitecture by ret

by temac 6y ago

Apple is competitive with Intel. Not ARM in a more general way. So I don't really see how Intel could magically produce a vastly better microarchitecture by retaking an ARM license... Especially since the microarchitecture is not completely independent from the ISA, and Intel is a specialist of x86, not ARM. So it would take a huge time to reach the same level. And that would not fix their process either... Plus to be competitive on perfs Apple is using some tricks (larger page size => huge impact on L1) that are maybe difficult to apply to Windows, given the Windows ARM ecosystem already exists (even if no very striving for now). Also MS is attempting a somehow closed ARM hw ecosystem, so that's not a full replacement for x86. To finish what to compare to is currently likely to be AMD, not Intel. So I think x86 is here to stay, or at least that's not the Apple switch that is going to initiate a revolution.

scarface74 6y ago
How many other companies are competitive with Intel using ARM based designs specialized for their own needs? I know Amazon is doing some amazing things around ARM for their own data centers - both selling access to ARM based servers and using custom chips for networking hardware. Isn’t Google also designing custom ARM chips for machine learning and their data centers?
- gsnedders 6y ago
  AFAIK, Amazon's ARM stuff is all based on ARM-designed cores (the Neoverse N1, presumably Cortex-X1 in future). Yes, all the integration is done by Amazon but the underlying ISA implementation is the same.
  - saagarjha 6y ago
    Didn’t they acquire Annapurna recently and are making their own thing?
    - gsnedders 6y ago
      Still based on ARM cores, far as I can tell? Plenty more on chip than just the cores, though.
skavi 6y ago
I've always wondered how independent µarchs are from ISAs. I mean people do say that Ryzen shares a lot of elements from AMD's ARM K12 project.
- temac 6y ago
  Well you have the multiprocessor memory model for example. Technically, you could use a stricter one (from x86) on arm, but that would maybe prevent some non-atomic efficiency gains, and if it's for a platform with competitor chips that do not do that, programs also won't be able to profit from your stricter model (and maybe Arm Holding won't even let you document it); maybe you will be faster on some atomic instructions though (because you have to be fast for even your non atomic ones anyway), but I doubt that would be beneficial in the majority of workloads. Clearly, there can be shared elements, but, if you want something optimized, not everything.
- phire 6y ago
  ARM has a more relaxed memory model that allows you to skip some uarch components. For example, the x86 instruction cache needs to watch for writes to instructions it's executing, while ARM derived CPUs can just ignore those writes. And ARMs fixed length instructions allow apple to just duplication their instruction decoder logic until they are decoding (currently) 7 instructions per cycle. With x86, you have to work out how long each instruction is to know where the next instruction starts. Intel and AMD actually try to decode an instruction starting at every single byte (over 16 bytes) letting the earlier instructions cancel out any incorrect instructions. With this scheme, Intel can only decode 5 instructions per cycle, while AMD are currently doing 4. And they both require certain complex instructions to always go in the first decoder. To overcome this bottleneck, Intel and AMD both cache decoded uops in an L0 cache to speed up tight loops. Intel can do 6 uops per cycle, AMD can max out at 8 uops. Apple can skip all this complexity. Their decoders operate at full speed and there is no need to cache uops. Beyond these two areas, the rest of the CPU core is reasonably ISA agnostic. The scheduling and execution units can stay the same, but the optimal balance of execution units might change based on the ISA. That balance also might change based on the type of code the CPU is expected to execute, and the compiler.
CyberDildonics 6y ago
Why would a larger page size be difficult to use with window? Also why would that have a huge impact on the L1 cache? Are you talking about cache lines being larger? Intel cpus actually always pull two cache lines from memory, so 128 bytes, even though a cache line is 64 bytes.
- temac 6y ago
  I'm not sure about the difficulty level of enlarging the pages in Windows. But I'm afraid there are 3rd party programs hardcoding it (and existing ARM hw they run on, etc.) But thinking more about it, IIRC Windows has a 64kB granularity at some level in mapping APIs, so maybe it's not as difficult as I initially thought. Not sure. Why it has an impact on L1? Because you don't want to perform address translation before beginning your L1 lookup (else the perfs would be shit). So you index your L1 cache by the LSb, which are the same in virtual and physical. So a bigger page size means more bits to index, and a bigger L1 without having to give it more ways. And if you can avoid more ways, its better because you have to compare the tags in all the ways, then mux the data out of the good one, so having tons of ways draw some power. That's why L1D is typically 32k on computers with 4kB pages: that gives 8 ways, which is OK. Intel went with 48k and 12 ways on Sunny Cove, but that's starting to be high. A12 is 128k L1D, with 16kB pages, if I'm not mistaken that's conveniently 8 ways.
  - formerly_proven 6y ago
    Larger pages also relieve TLB pressure somewhat and reduce page table size, although large memory areas are supposed to just use giant pages anyway. It's worth pointing out that L1 is universally split into L1I and L1D of usually the same size, so for x86 mainstream L1 is specified as 64 KB, meaning 32K+32K for instructions and data, respectively.
  - saagarjha 6y ago
    > But I'm afraid there are 3rd party programs hardcoding it (and existing ARM hw they run on, etc.) Of course just about every JIT runtime does this.
jorvi 6y ago
> So I think x86 is here to stay, or at least that's not the Apple switch that is going to initiate a revolution. It will, indirectly. When MacBooks offer 1.5x the performance at 2x the battery life, people using Windows or Linux will start to demand similar devices from Dell, Lenovo, HP, Acer, etc; It makes me the saddest for AMD. They’ve just clawed back a few victories from a decade of loss, and starting within 5 years that will hardly matter. As for the customer: this will be an amazing time, especially if we will finally get some standardization around ARM SoCs. Apparently every single one of them (at least phones) does their own little boot quirks, instead of their being a unified BIOS or EFI or whatever to guide it all.
- temac 6y ago
  > It will, indirectly. When MacBooks offer 1.5x the performance at 2x the battery life, people using Windows or Linux will start to demand similar devices from Dell, Lenovo, HP, Acer, etc; Well, people can demand that, but if only Apple knows how to design the chips, and given they will not sell them to competitors...
  - baconandeggs 6y ago
    Users don't want chips they want systems and the way people will "demand" them will be by buying Apple. Dell and Lenovo will have to come up with something or cede market share.
    - Dylan16807 6y ago
      That's the direct pressure, not the indirect pressure. And yeah it'll exist but if they decide not to make the OS replaceable then there's going to be a severe dampening effect on people switching to Apple hardware. So we'll see on that front.
    - pjmlp 6y ago
      Where I come from, people won't certainly be rushing to buy Apple with 300 euros as minimum wage and 1000 euros on average for regular IT job.
bluedino 6y ago
Is the only thing that can ruin Apple’s plans are the chips not being “general purpose enough” or something and not running well?
- alwillis 6y ago
  Apple has been working on this transition for years. Just like they were running MacOS X on Intel long before they announced the Intel transition, you know there have been ARM-based Macs for a few years now. It's early, but these benchmarks from the DTK looks really promising: https://gizmodo.com/a-wild-apple-arm-benchmark-appears-1844204355 https://gizmodo.com/a-wild-apple-arm-benchmark-appears-18442...
  - saagarjha 6y ago
    Benchmarks while emulating x86_64!
paulpan 6y ago
Agreed that x86 isn't going anywhere, at least for another decade. The point is that we're about to embark on some very interesting and untested waters for the overall silicon/semiconductor industry. The collapse of so-called "Wintel" will not be directly from Apple's move to switch to their own silicon, but as a second order effect on the other OEMs such as HP, Dell, Lenovo. Just as they're reaching build parity (e.g. XPS 13, X1 Carbon) with Apple's Macbook offerings, Apple is potentially about to pivot and take a lead in where they can't follow - in CPU performance. Make no mistake that ARM-based Macbooks will easily surpass the performance on the existing Intel-based offerings. What will Dell, HP, and Lenovo do to be competitive? Microsoft has arguably seen this risk and trying to mitigate with shifting Windows to ARM. But there's a big problem - Qualcomm is not Intel and their chips as-is (e.g. SD845) have both compatibility and performance issues. Are there any alternatives? AMD could bring back their shelved "Seattle" chips, or maybe Intel's Lakefield platform will be fruitful, or even Nvidia will join the fray with a worthy Orin-successor? Very interesting times ahead indeed...

by temac 6y ago

scarface74 6y ago

How many other companies are competitive with Intel using ARM based designs specialized for their own needs? I know Amazon is doing some amazing things around ARM for their own data centers - both selling access to ARM based servers and using custom chips for networking hardware. Isn’t Google also designing custom ARM chips for machine learning and their data centers?

gsnedders 6y ago
AFAIK, Amazon's ARM stuff is all based on ARM-designed cores (the Neoverse N1, presumably Cortex-X1 in future). Yes, all the integration is done by Amazon but the underlying ISA implementation is the same.
- saagarjha 6y ago
  Didn’t they acquire Annapurna recently and are making their own thing?
  - gsnedders 6y ago
    Still based on ARM cores, far as I can tell? Plenty more on chip than just the cores, though.

skavi 6y ago

I've always wondered how independent µarchs are from ISAs. I mean people do say that Ryzen shares a lot of elements from AMD's ARM K12 project.

temac 6y ago
Well you have the multiprocessor memory model for example. Technically, you could use a stricter one (from x86) on arm, but that would maybe prevent some non-atomic efficiency gains, and if it's for a platform with competitor chips that do not do that, programs also won't be able to profit from your stricter model (and maybe Arm Holding won't even let you document it); maybe you will be faster on some atomic instructions though (because you have to be fast for even your non atomic ones anyway), but I doubt that would be beneficial in the majority of workloads. Clearly, there can be shared elements, but, if you want something optimized, not everything.
phire 6y ago
ARM has a more relaxed memory model that allows you to skip some uarch components. For example, the x86 instruction cache needs to watch for writes to instructions it's executing, while ARM derived CPUs can just ignore those writes. And ARMs fixed length instructions allow apple to just duplication their instruction decoder logic until they are decoding (currently) 7 instructions per cycle. With x86, you have to work out how long each instruction is to know where the next instruction starts. Intel and AMD actually try to decode an instruction starting at every single byte (over 16 bytes) letting the earlier instructions cancel out any incorrect instructions. With this scheme, Intel can only decode 5 instructions per cycle, while AMD are currently doing 4. And they both require certain complex instructions to always go in the first decoder. To overcome this bottleneck, Intel and AMD both cache decoded uops in an L0 cache to speed up tight loops. Intel can do 6 uops per cycle, AMD can max out at 8 uops. Apple can skip all this complexity. Their decoders operate at full speed and there is no need to cache uops. Beyond these two areas, the rest of the CPU core is reasonably ISA agnostic. The scheduling and execution units can stay the same, but the optimal balance of execution units might change based on the ISA. That balance also might change based on the type of code the CPU is expected to execute, and the compiler.

CyberDildonics 6y ago

Why would a larger page size be difficult to use with window? Also why would that have a huge impact on the L1 cache? Are you talking about cache lines being larger? Intel cpus actually always pull two cache lines from memory, so 128 bytes, even though a cache line is 64 bytes.

temac 6y ago
I'm not sure about the difficulty level of enlarging the pages in Windows. But I'm afraid there are 3rd party programs hardcoding it (and existing ARM hw they run on, etc.) But thinking more about it, IIRC Windows has a 64kB granularity at some level in mapping APIs, so maybe it's not as difficult as I initially thought. Not sure. Why it has an impact on L1? Because you don't want to perform address translation before beginning your L1 lookup (else the perfs would be shit). So you index your L1 cache by the LSb, which are the same in virtual and physical. So a bigger page size means more bits to index, and a bigger L1 without having to give it more ways. And if you can avoid more ways, its better because you have to compare the tags in all the ways, then mux the data out of the good one, so having tons of ways draw some power. That's why L1D is typically 32k on computers with 4kB pages: that gives 8 ways, which is OK. Intel went with 48k and 12 ways on Sunny Cove, but that's starting to be high. A12 is 128k L1D, with 16kB pages, if I'm not mistaken that's conveniently 8 ways.
- formerly_proven 6y ago
  Larger pages also relieve TLB pressure somewhat and reduce page table size, although large memory areas are supposed to just use giant pages anyway. It's worth pointing out that L1 is universally split into L1I and L1D of usually the same size, so for x86 mainstream L1 is specified as 64 KB, meaning 32K+32K for instructions and data, respectively.
- saagarjha 6y ago
  > But I'm afraid there are 3rd party programs hardcoding it (and existing ARM hw they run on, etc.) Of course just about every JIT runtime does this.

jorvi 6y ago

> So I think x86 is here to stay, or at least that's not the Apple switch that is going to initiate a revolution. It will, indirectly. When MacBooks offer 1.5x the performance at 2x the battery life, people using Windows or Linux will start to demand similar devices from Dell, Lenovo, HP, Acer, etc; It makes me the saddest for AMD. They’ve just clawed back a few victories from a decade of loss, and starting within 5 years that will hardly matter. As for the customer: this will be an amazing time, especially if we will finally get some standardization around ARM SoCs. Apparently every single one of them (at least phones) does their own little boot quirks, instead of their being a unified BIOS or EFI or whatever to guide it all.

temac 6y ago
> It will, indirectly. When MacBooks offer 1.5x the performance at 2x the battery life, people using Windows or Linux will start to demand similar devices from Dell, Lenovo, HP, Acer, etc; Well, people can demand that, but if only Apple knows how to design the chips, and given they will not sell them to competitors...
- baconandeggs 6y ago
  Users don't want chips they want systems and the way people will "demand" them will be by buying Apple. Dell and Lenovo will have to come up with something or cede market share.
  - Dylan16807 6y ago
    That's the direct pressure, not the indirect pressure. And yeah it'll exist but if they decide not to make the OS replaceable then there's going to be a severe dampening effect on people switching to Apple hardware. So we'll see on that front.
  - pjmlp 6y ago
    Where I come from, people won't certainly be rushing to buy Apple with 300 euros as minimum wage and 1000 euros on average for regular IT job.

bluedino 6y ago

Is the only thing that can ruin Apple’s plans are the chips not being “general purpose enough” or something and not running well?

alwillis 6y ago
Apple has been working on this transition for years. Just like they were running MacOS X on Intel long before they announced the Intel transition, you know there have been ARM-based Macs for a few years now. It's early, but these benchmarks from the DTK looks really promising: https://gizmodo.com/a-wild-apple-arm-benchmark-appears-1844204355 https://gizmodo.com/a-wild-apple-arm-benchmark-appears-18442...
- saagarjha 6y ago
  Benchmarks while emulating x86_64!

paulpan 6y ago

Agreed that x86 isn't going anywhere, at least for another decade. The point is that we're about to embark on some very interesting and untested waters for the overall silicon/semiconductor industry. The collapse of so-called "Wintel" will not be directly from Apple's move to switch to their own silicon, but as a second order effect on the other OEMs such as HP, Dell, Lenovo. Just as they're reaching build parity (e.g. XPS 13, X1 Carbon) with Apple's Macbook offerings, Apple is potentially about to pivot and take a lead in where they can't follow - in CPU performance. Make no mistake that ARM-based Macbooks will easily surpass the performance on the existing Intel-based offerings. What will Dell, HP, and Lenovo do to be competitive? Microsoft has arguably seen this risk and trying to mitigate with shifting Windows to ARM. But there's a big problem - Qualcomm is not Intel and their chips as-is (e.g. SD845) have both compatibility and performance issues. Are there any alternatives? AMD could bring back their shelved "Seattle" chips, or maybe Intel's Lakefield platform will be fruitful, or even Nvidia will join the fray with a worthy Orin-successor? Very interesting times ahead indeed...