5 ms·

One factor called out in the article is the number of instructions that can be carried out simultaneously during a single clock cycle. >Monsoon (A11) and Vorte

One factor called out in the article is the number of instructions that can be carried out simultaneously during a single clock cycle. >Monsoon (A11) and Vortex (A12) are extremely wide machines – with 6 integer execution pipelines among which two are complex units, two load units and store units, two branch ports, and three FP/vector pipelines this gives an estimated 13 execution ports, far wider than Arm’s upcoming Cortex A76 and also wider than Samsung’s M3. In fact, assuming we're not looking at an atypical shared port situation, Apple’s microarchitecture seems to far surpass anything else in terms of width, including desktop CPUs. https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-review-unveiling-the-silicon-secrets/3 https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re... Apple first moved to wide CPU designs with the Cyclone CPU core found in the A7 SOC first used in the iPhone 5s. >With Cyclone Apple is in a completely different league. As far as I can tell, peak issue width of Cyclone is 6 instructions. That’s at least 2x the width of Swift and Krait, and at best more than 3x the width depending on instruction mix. Limitations on co-issuing FP and integer math have also been lifted as you can run up to four integer adds and two FP adds in parallel. You can also perform up to two loads or stores per clock. https://www.anandtech.com/show/7460/apple-ipad-air-review/2 https://www.anandtech.com/show/7460/apple-ipad-air-review/2

baybal2 8y ago
NetBurst... ?
- stephencanon 8y ago
  NetBurst was 4-wide with (IIRC) two of those ports double-pumped for certain operations, but limited to 4/cycle retire, I think.
  - rayiner 8y ago
    NetBurst (like the P6 architecture before it) was 3-way decode/3-way retire. (Actually, NetBurst could decode just one x86 op per cycle into the trace cache; the trace cache could deliver 3 uops per cycle if there was a cache hit.)
rayiner 8y ago
That's part of it, but doesn't fully answer the question. Decoding and issuing 6 instructions per cycle ordinarily is extremely costly in terms of power. And it's usually very hard to keep those execution units busy--it's hard to find six independent instructions to issue every clock cycle. How Apple built a 6-wide CPU within that power envelope, and optimized the compiler to actually use that IPC is the really interesting question. On a Xeon v3 core, SPECint averages below 2 instructions per cycle: https://www.researchgate.net/publication/322745869_A_Workload_Characterization_of_the_SPEC_CPU2017_Benchmark_Suite https://www.researchgate.net/publication/322745869_A_Workloa.... How does Apple beat Intel on branch integer benchmarks like 403.gcc by a factor of two per clock?
- amluto 8y ago
  One respect in which I can imagine the x86 ISA being a real problem is in decode bandwidth. To issue 6 x86 instructions per cycle, either the front end needs to decode 6 per cycle, or it needs to cache decoded instructions. And x86 can’t be decoded in parallel without massive complexity because the instructions are variable length, and even determining the length requires mostly decoding the instruction.
  - rayiner 8y ago
    It's true that decoding x86 is harder, but Sandy Bridge+ get most instructions from a uop cache, which delivers 4 fixed-length uops per cycle. You could make that 6 wide, but Intel doesn't because they wouldn't be able to fill that.
    - pcwalton 8y ago
      AArch64 has a larger register file and fewer dependencies in general than x86-64 does. For example, most instructions don't set flags. I don't know for sure, but that might be enough to raise the ILP sufficiently.
- Symmetry 8y ago
  Lower maximum clock speeds mean you have more FO4s to play with and potentially makes the fan-out issues in wide designs a bit more manageable. Decode I expect to be pretty easy, as long as your branch predictor is on target the power costs just grow linearly with decode width when all your instructions start at nice 32-bit boundaries. Mostly I'm curious about how complete the bypass network is on their functional units and if execution is clustered like the POWER8. The width doubling in the A series does remind me of the POWER 7 to 8 transition. Renaming is also apparently a major constraint on design width in many cases but I'm not so familiar with that.

baybal2 8y ago

NetBurst... ?

stephencanon 8y ago
NetBurst was 4-wide with (IIRC) two of those ports double-pumped for certain operations, but limited to 4/cycle retire, I think.
- rayiner 8y ago
  NetBurst (like the P6 architecture before it) was 3-way decode/3-way retire. (Actually, NetBurst could decode just one x86 op per cycle into the trace cache; the trace cache could deliver 3 uops per cycle if there was a cache hit.)

rayiner 8y ago

That's part of it, but doesn't fully answer the question. Decoding and issuing 6 instructions per cycle ordinarily is extremely costly in terms of power. And it's usually very hard to keep those execution units busy--it's hard to find six independent instructions to issue every clock cycle. How Apple built a 6-wide CPU within that power envelope, and optimized the compiler to actually use that IPC is the really interesting question. On a Xeon v3 core, SPECint averages below 2 instructions per cycle: https://www.researchgate.net/publication/322745869_A_Workload_Characterization_of_the_SPEC_CPU2017_Benchmark_Suite https://www.researchgate.net/publication/322745869_A_Workloa.... How does Apple beat Intel on branch integer benchmarks like 403.gcc by a factor of two per clock?

amluto 8y ago
One respect in which I can imagine the x86 ISA being a real problem is in decode bandwidth. To issue 6 x86 instructions per cycle, either the front end needs to decode 6 per cycle, or it needs to cache decoded instructions. And x86 can’t be decoded in parallel without massive complexity because the instructions are variable length, and even determining the length requires mostly decoding the instruction.
- rayiner 8y ago
  It's true that decoding x86 is harder, but Sandy Bridge+ get most instructions from a uop cache, which delivers 4 fixed-length uops per cycle. You could make that 6 wide, but Intel doesn't because they wouldn't be able to fill that.
  - pcwalton 8y ago
    AArch64 has a larger register file and fewer dependencies in general than x86-64 does. For example, most instructions don't set flags. I don't know for sure, but that might be enough to raise the ILP sufficiently.
Symmetry 8y ago
Lower maximum clock speeds mean you have more FO4s to play with and potentially makes the fan-out issues in wide designs a bit more manageable. Decode I expect to be pretty easy, as long as your branch predictor is on target the power costs just grow linearly with decode width when all your instructions start at nice 32-bit boundaries. Mostly I'm curious about how complete the bypass network is on their functional units and if execution is clustered like the POWER8. The width doubling in the A series does remind me of the POWER 7 to 8 transition. Renaming is also apparently a major constraint on design width in many cases but I'm not so familiar with that.