China's Loongson CPU seems to have IPC equivalent to Zen 4 and Raptor Lake -- but slow speeds and limited core count keeps 3A6000 well behind modern competition

The Historical Fidelity said:

It seems like the loongson cpu is using a short pipeline to yield similar IPC to AMD and Intel’s 14+ stage pipeline.

It could be, but we can't say for sure.
Clockspeeds aren't just a function of architecture, but the capability of the circuit designers and layout engineers in the team.

bit_user said:

The IPC of leading x86 CPUs is partly being held back by the ISA. I'm eager to see how the upcoming ARM cores from Qualcomm, AMD, Nvidia and others will compare.

The 90's called, they want their claims back.

Modern CPUs with billions of transistors aren't limited by the decoders anymore. That has been long past when engineers had transistor budgets measuring in the hundreds of thousands range.

Simple reason ARM vendors are leading is because both AMD/Intel has fallen completely flat on it's face over the years. You can tell by the comparison between AMD/Nvidia. The latter had far, far less missteps.

DEC in the 90's led everyone else despite having the same RISC instruction set. Then the team of DEC went to eventually work at Apple through acquisition of PA Semi. Along with them they had other brilliant engineers like Gerald Williams III, who moved on to find Nuvia, and breaking records again. As soon as Gerald left Apple, we had 4 generations of minimal gains from Apple chips.

Because we're outsiders it's very easy to fall into the trap the often clueless high level management with finance degrees fall into - the belief that it's the "tech" that makes the difference, when it's the ingenuity, perseverance, and creativity of the people that do.

The no-clues talked about the complexity of Sapphire Rapids as being the reason for downfall, when people in the know told for years how the management team led by Kraznich fired the ENTIRE SPR validation team at some point. That couldn't have had anything to do with SPR being delayed for 3+ years can't it?

DavidC1 said:

The 90's called, they want their claims back.

Look, I've been through this debate so many times I can't even keep track of whether or how many times I've debated it with you. So, I'm going to keep this short & sweet.
AArch64 has an undeniable advantage in that its ISA is cheaper to decode and easier to scale up decoding. ARM's Cortex-X4 has a 10-way decoder, while Intel's Golden Cove is currently at just 6-way, and only a couple of those are fully general.
AArch64 has a more efficient memory consistency model.
AArch64 has twice as many general-purpose registers.
AArch64's SVE2 enables flexible scaling of vector width, without rewriting code. In a CPU with AVX10/512, the extra width potentially goes to waste, when executing code written with AVX2 or AVX10/256.
AArch64 has a 3-operand format, for most instructions, reducing the need for additional mov's.
Intel's announcement of APX is clear evidence that Intel is worried. Of the above advantages I listed, it enables them only to take #3 and #5 off the table. In exchange, it adds yet another prefix byte, which makes #1 even worse.

DavidC1 said:

Modern CPUs with billions of transistors aren't limited by the decoders anymore.

Their width can be a bottleneck. So, even if you take the area impact of the table, decoders still matter. I believe the power they require can also be relevant, in certain contexts.

DavidC1 said:

the management team led by Kraznich fired the ENTIRE SPR validation team at some point. That couldn't have had anything to do with SPR being delayed for 3+ years can't it?

Most of Sapphire Rapids' delay was due to manufacturing process, not validation. The bugs plaguing Sapphire Rapids only accounted for about the final year of delays in its launch date.

DavidC1 said:

It could be, but we can't say for sure.
Clockspeeds aren't just a function of architecture, but the capability of the circuit designers and layout engineers in the team.

The 90's called, they want their claims back.

Modern CPUs with billions of transistors aren't limited by the decoders anymore. That has been long past when engineers had transistor budgets measuring in the hundreds of thousands range.

Simple reason ARM vendors are leading is because both AMD/Intel has fallen completely flat on it's face over the years. You can tell by the comparison between AMD/Nvidia. The latter had far, far less missteps.

DEC in the 90's led everyone else despite having the same RISC instruction set. Then the team of DEC went to eventually work at Apple through acquisition of PA Semi. Along with them they had other brilliant engineers like Gerald Williams III, who moved on to find Nuvia, and breaking records again. As soon as Gerald left Apple, we had 4 generations of minimal gains from Apple chips.

Because we're outsiders it's very easy to fall into the trap the often clueless high level management with finance degrees fall into - the belief that it's the "tech" that makes the difference, when it's the ingenuity, perseverance, and creativity of the people that do.

The no-clues talked about the complexity of Sapphire Rapids as being the reason for downfall, when people in the know told for years how the management team led by Kraznich fired the ENTIRE SPR validation team at some point. That couldn't have had anything to do with SPR being delayed for 3+ years can't it?

It could be circuit design and layout but that seems too rudimentary to mess up and this be the culprit. Im leaning towards a short pipeline, as one of the hardest parts of micro-architecture design is a high confidence branch predictor which becomes more and more important the longer the pipeline becomes as a mis-prediction will cause the entire pipeline to be flushed and the instructions to be re-run. A short pipeline can achieve high IPC with a low confidence branch predictor since the number of instructions flushed is maximum = to the number of stages. This is why pentium 4 was regarded as hot garbage with its 20+ stage pipeline mated with a mis-prediction prone branch predictor even though pentium 3’s branch predictor was objectively worse. I’m theorizing loongson does not have the experience in branch prediction to create a branch predictor that can be mated to a long pipeline design. However I could be wrong.

The Historical Fidelity said:

Im leaning towards a short pipeline, as one of the hardest parts of micro-architecture design is a high confidence branch predictor which becomes more and more important the longer the pipeline becomes as a mis-prediction will cause the entire pipeline to be flushed and the instructions to be re-run.

Branch prediction seems like the kind of thing which can be somewhat decoupled from the pipeline, itself. Also, as painful as it is to invalidate speculative executions, probably the bigger penalty associated with mispredections is having to take the latency hit of fetching instructions down the path you failed to predict. Especially if it's nowhere in the cache hierarchy, since DRAM can easily be around 500 cycles away!

BTW, don't forget that memory prefetchers are an important form of prediction.

The Historical Fidelity said:

A short pipeline can achieve high IPC with a low confidence branch predictor since the number of instructions flushed is maximum = to the number of stages. This is why pentium 4 was regarded as hot garbage with its 20+ stage pipeline mated with a mis-prediction prone branch predictor even though pentium 3’s branch predictor was objectively worse.

This model of IPC is too simplistic. Since the days of Core 2, pipelines have again started to get longer, yet IPC has continued to increase.

bit_user said:

Branch prediction seems like the kind of thing which can be somewhat decoupled from the pipeline, itself. Also, as painful as it is to invalidate speculative executions, probably the bigger penalty associated with mispredections is having to take the latency hit of fetching instructions down the path you failed to predict.

BTW, don't forget that memory prefetchers are an important form of prediction.


This model of IPC is too simplistic. Since the days of Core 2, pipelines have again started to get longer, yet IPC has continued to increase.

Oh I wasn’t saying that pipeline length is the only thing that affects IPC, the parts feeding the pipeline are also important to IPC. And today’s AMD/Intel designs are actually dynamic pipeline length, I believe Zen and Intel can be 14-19 stages depending on workload. That’s actually not that much of an increase from the original Core architectures 12-stages and Core 2’s 16 stages. Mind you, Core came right after Netburst Prescott with its 31-stage pipeline. Sandybridge to kabylake Intel architectures have all maintained a 14-19 stage dynamic pipeline so not really that much longer than the original core. I can’t seem to find any data on the number of stages in alderlake and newer architectures however it seems both Intel and AMD have decided 14-19 stages is the optimal length.

I’m simply saying that shortening the pipeline is an easy way to increase IPC to compete with AMD/Intel if the 3a6000’s architecture is unable to hit similar IPC with the same pipeline length. And if they did decide to shorten the pipeline for said reason, then it could explain why 3 ghz with liquid nitrogen cooling is the max stable clock assuming SMIC’s 12nm process and loongson’s circuit design and layout is competently designed.

And then my addition of branch predictor design was just to show to add more reinforcement that it is much simpler to increase IPC by shortening the pipeline as longer pipelines require more and more sophisticated front end (branch prediction, instruction fetch, buffers, schedulers, etc.) and backend (catch population and hit rates, etc.) to maintain the same IPC as a shorter pipeline.

But you are right that front end and backend optimization is key to increasing IPC in long pipeline designs as the longer the pipeline, the more perfect the front/backend must be to keep the pipeline fully utilized. Like in my example with pentium 3/4, going from a 10-stage pipeline to a 20-stage pipeline required an increase of 566mhz clock speed to match the pentium 3’s performance despite pentium 4’s improved front/back end. And when Prescott came out, it’s 31-stage pipeline was so long that AMD had the better processor even though it couldn’t clock nearly as high.

The Historical Fidelity said:

Oh I wasn’t saying that pipeline length is the only thing that affects IPC, the parts feeding the pipeline are also important to IPC. And today’s AMD/Intel designs are actually dynamic pipeline length, I believe Zen and Intel can be 14-19 stages depending on workload. That’s actually not that much of an increase from the original Core architectures 12-stages and Core 2’s 16 stages. Mind you, Core came right after Netburst Prescott with its 31-stage pipeline. Sandybridge to kabylake Intel architectures have all maintained a 14-19 stage dynamic pipeline so not really that much longer than the original core. I can’t seem to find any data on the number of stages in alderlake and newer architectures however it seems both Intel and AMD have decided 14-19 stages is the optimal length.

I’m simply saying that shortening the pipeline is an easy way to increase IPC to compete with AMD/Intel if the 3a6000’s architecture is unable to hit similar IPC with the same pipeline length. And if they did decide to shorten the pipeline for said reason, then it could explain why 3 ghz with liquid nitrogen cooling is the max stable clock assuming SMIC’s 12nm process and loongson’s circuit design and layout is competently designed.

And then my addition of branch predictor design was just to show to add more reinforcement that it is much simpler to increase IPC by shortening the pipeline as longer pipelines require more and more sophisticated front end (branch prediction, instruction fetch, buffers, schedulers, etc.) and backend (catch population and hit rates, etc.) to maintain the same IPC as a shorter pipeline.

But you are right that front end and backend optimization is key to increasing IPC in long pipeline designs as the longer the pipeline, the more perfect the front/backend must be to keep the pipeline fully utilized. Like in my example with pentium 3/4, going from a 10-stage pipeline to a 20-stage pipeline required an increase of 566mhz clock speed to match the pentium 3’s performance despite pentium 4’s improved front/back end. And when Prescott came out, it’s 31-stage pipeline was so long that AMD had the better processor even though it couldn’t clock nearly as high.

Zen only has a 19 stage pipeline, Intel’s current P-core CPUs have a 15-20 stage pipeline since Alder Lake