5 ms·

It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely

It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy code gets 3-way decoding.

deaddodo 2y ago
> With E cores like this, who needs P cores? Because, presumably, the P-cores are even beefier. Intel and AMD are still trying to gain time on the slow march to ARM (particularly Apple) catching up. Both of their long term strategies seem to differ (AMD edging back into ARM itself, Intel being a little more close lipped), but they can't lose their one major edge (raw performance) or potentially more users switch to an x86-excluded (and, more importantly, third-party excluded) platform (Mac).
- metadat 2y ago
  Is ARM really that special? Why do you believe this is the case?
  - thunderbird120 2y ago
    The ISA is much less important than many people seem to think. The RISC vs CISC debate is beyond outdated at this point because no modern architecture actually works strictly like either under the hood. Organizations who did x86 architectures historically had much more emphasis on performance while organizations who did ARM had more emphasis on low power devices. The lingering engineering consequences of that history and the experience of the organizations doing design are orders of magnitude more relevant than the difference in actual ISA.
  - Dalewyn 2y ago
    ARM is special in that it's the only potential, realistic competitor to x86 left in the entire industry. RISC-V? Only if you're a zealot breathing fumes for life energy, at least as things stand today.
    - gary_0 2y ago
      The interesting thing about RISC-V is that there are like 10 billion RISC-V microcontrollers out there that otherwise would have been ARM. So ARM has been moving into the PC/server space while RISC-V pushes in from behind, at the opposite end of the line from x86.
      - cptskippy 2y ago
        RISC-V is disrupting ARM's low end, the pace it's occupied safely for decades. As RISC-V matures, it will move upstream along the same path that ARM did. The difference is that it will be easier to move because the transition to ARM is demonstrating that companies don't need to be locked to a particular ISA.
  - deaddodo 2y ago
    ARM is simply the ISA the industry is pivoting to and where most forward investment is going. I don't know where I implied it was special.
- pclmulqdq 2y ago
  In all seriousness, the main advantage of the P cores is the wider vector datapath. They are much more set up for loopy "grunt work" like matrix math. Web serving probably doesn't need a P core, for example.
- jorvi 2y ago
  > or potentially more users switch to an x86-excluded (and, more importantly, third-party excluded) platform (Mac). Or much more likely, Windows ARM.
phire 2y ago
> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigger waste to have two extra decoders. Intel's actual approach is way more clever; They run the branch predictor ahead of the decoders by at least 3 branches (probably more). The branch predictor can spit out a new prediction every cycle, and it just plops them on a queue. Each of the three decoders pops a branch prediction off the queue and starts decoding there. At any time, all three decoders will each be decoding a different basic block. A basic block that the branch predictor has predicted that the program counter is about to flow through. The three decoders are leap frogging each other. The decoding of each basic block is limited to a throughput of three instructions per cycle, but Skymont is decoding three basic blocks in parallel. The decoded uops get pushed onto three independent queues, and the re-namer/dispatcher merges these three queues back together in original program order before dispatching to the backend. Each decoder can only push three uops per cycle onto its queue, but the re-namer/dispatcher can pull them off a single queue at the rate of 9 uops per cycle. The other two queues will continue to fill up while one queue is being drained. The branch prediction result will always land on an instruction boundary, so this design allows the three decoders to combine their efforts and maintain a throughput of 9 uops per cycle, as long as the code is branchy enough. It works on loops too, as far as I'm aware, intel doesn't even have a loop stream buffer on this design; The three decoders will be decoding the exact same instructions in parallel for loop bodies. But Intel have a neat trick to make this work even on code without branches or loops. The branch predictor actually inserts fake branches into the middle of long basic blocks. The branch predictor isn't actually checking an address to see if it has a branch. Instead it predicts the gap between branches, and they simply have a limit for the size of those gaps. Looks like that limit for Skymont is 64 bytes (was previously 32 bytes for Crestmont)
- Marthinwurer 2y ago
  Thank you for that explanation, I was confused as to what was happening with the multiple decoders. That's a wild way to implement a processor front end.
ls612 2y ago
I did the math and even on current 13900k/14900k chips each E-core is roughly equivalent to a stock Skylake 6700k core.
skavi 2y ago
The two generation old Gracemont already beat Skylake [0]. Skymont can beat Raptor Cove [1] (The big core that was paired with Gracemont). [0]: https://www.anandtech.com/show/16881/a-deep-dive-into-intels-alder-lake-microarchitectures/4 https://www.anandtech.com/show/16881/a-deep-dive-into-intels... [1]: https://www.anandtech.com/show/21425/intel-lunar-lake-architecture-deep-dive-lion-cove-xe2-and-npu4/3 https://www.anandtech.com/show/21425/intel-lunar-lake-archit...
wffurr 2y ago
Classic disrupting yourself from below. A little late now that ARM chips from both Apple and now Qualcomm (maybe?) have caught up, but the second best time is now. I give it 2 more releases max before Intel drops heterogeneous cores and only ships the -Mont architecture.
- BearOso 2y ago
  Agreed. We've seen this before. Pentium M -> Core.
dur-randir 2y ago
>With E cores like this, who needs P cores? Based on their the current performance, anyone who need it.

deaddodo 2y ago

> With E cores like this, who needs P cores? Because, presumably, the P-cores are even beefier. Intel and AMD are still trying to gain time on the slow march to ARM (particularly Apple) catching up. Both of their long term strategies seem to differ (AMD edging back into ARM itself, Intel being a little more close lipped), but they can't lose their one major edge (raw performance) or potentially more users switch to an x86-excluded (and, more importantly, third-party excluded) platform (Mac).

metadat 2y ago
Is ARM really that special? Why do you believe this is the case?
- thunderbird120 2y ago
  The ISA is much less important than many people seem to think. The RISC vs CISC debate is beyond outdated at this point because no modern architecture actually works strictly like either under the hood. Organizations who did x86 architectures historically had much more emphasis on performance while organizations who did ARM had more emphasis on low power devices. The lingering engineering consequences of that history and the experience of the organizations doing design are orders of magnitude more relevant than the difference in actual ISA.
- Dalewyn 2y ago
  ARM is special in that it's the only potential, realistic competitor to x86 left in the entire industry. RISC-V? Only if you're a zealot breathing fumes for life energy, at least as things stand today.
  - gary_0 2y ago
    The interesting thing about RISC-V is that there are like 10 billion RISC-V microcontrollers out there that otherwise would have been ARM. So ARM has been moving into the PC/server space while RISC-V pushes in from behind, at the opposite end of the line from x86.
    - cptskippy 2y ago
      RISC-V is disrupting ARM's low end, the pace it's occupied safely for decades. As RISC-V matures, it will move upstream along the same path that ARM did. The difference is that it will be easier to move because the transition to ARM is demonstrating that companies don't need to be locked to a particular ISA.
- deaddodo 2y ago
  ARM is simply the ISA the industry is pivoting to and where most forward investment is going. I don't know where I implied it was special.
pclmulqdq 2y ago
In all seriousness, the main advantage of the P cores is the wider vector datapath. They are much more set up for loopy "grunt work" like matrix math. Web serving probably doesn't need a P core, for example.
jorvi 2y ago
> or potentially more users switch to an x86-excluded (and, more importantly, third-party excluded) platform (Mac). Or much more likely, Windows ARM.

phire 2y ago

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigger waste to have two extra decoders. Intel's actual approach is way more clever; They run the branch predictor ahead of the decoders by at least 3 branches (probably more). The branch predictor can spit out a new prediction every cycle, and it just plops them on a queue. Each of the three decoders pops a branch prediction off the queue and starts decoding there. At any time, all three decoders will each be decoding a different basic block. A basic block that the branch predictor has predicted that the program counter is about to flow through. The three decoders are leap frogging each other. The decoding of each basic block is limited to a throughput of three instructions per cycle, but Skymont is decoding three basic blocks in parallel. The decoded uops get pushed onto three independent queues, and the re-namer/dispatcher merges these three queues back together in original program order before dispatching to the backend. Each decoder can only push three uops per cycle onto its queue, but the re-namer/dispatcher can pull them off a single queue at the rate of 9 uops per cycle. The other two queues will continue to fill up while one queue is being drained. The branch prediction result will always land on an instruction boundary, so this design allows the three decoders to combine their efforts and maintain a throughput of 9 uops per cycle, as long as the code is branchy enough. It works on loops too, as far as I'm aware, intel doesn't even have a loop stream buffer on this design; The three decoders will be decoding the exact same instructions in parallel for loop bodies. But Intel have a neat trick to make this work even on code without branches or loops. The branch predictor actually inserts fake branches into the middle of long basic blocks. The branch predictor isn't actually checking an address to see if it has a branch. Instead it predicts the gap between branches, and they simply have a limit for the size of those gaps. Looks like that limit for Skymont is 64 bytes (was previously 32 bytes for Crestmont)

Marthinwurer 2y ago
Thank you for that explanation, I was confused as to what was happening with the multiple decoders. That's a wild way to implement a processor front end.

ls612 2y ago

I did the math and even on current 13900k/14900k chips each E-core is roughly equivalent to a stock Skylake 6700k core.

skavi 2y ago

The two generation old Gracemont already beat Skylake [0]. Skymont can beat Raptor Cove [1] (The big core that was paired with Gracemont). [0]: https://www.anandtech.com/show/16881/a-deep-dive-into-intels-alder-lake-microarchitectures/4 https://www.anandtech.com/show/16881/a-deep-dive-into-intels... [1]: https://www.anandtech.com/show/21425/intel-lunar-lake-architecture-deep-dive-lion-cove-xe2-and-npu4/3 https://www.anandtech.com/show/21425/intel-lunar-lake-archit...

wffurr 2y ago

Classic disrupting yourself from below. A little late now that ARM chips from both Apple and now Qualcomm (maybe?) have caught up, but the second best time is now. I give it 2 more releases max before Intel drops heterogeneous cores and only ships the -Mont architecture.

BearOso 2y ago
Agreed. We've seen this before. Pentium M -> Core.

dur-randir 2y ago

>With E cores like this, who needs P cores? Based on their the current performance, anyone who need it.