Abstract
Superscalar out-of-order execution cores have grown steadily wider over two decades. Intel’s P-cores in Raptor Lake and Meteor Lake issue up to 6 micro-ops per cycle; ARM’s Cortex-X4 targets 6-wide issue as well; Apple’s Firestorm and Everest cores have been measured at 8-wide in practice. The question of whether continued width scaling delivers proportional performance gains is receiving renewed scrutiny, both from academic microarchitecture researchers and from the design teams that must translate wider front-ends and larger reorder buffers into power and area budgets at N3 and N2. The relationship between issue width, instruction-level parallelism in real workloads, and the structural costs of width scaling is more constrained than the headline numbers suggest.
Where ILP Runs Out
Instruction-level parallelism (ILP) in real programs is bounded by data dependences, control flow, and memory latency. Tomasulo’s classic analysis and its modern descendants show that for general-purpose integer workloads, average ILP across typical SPEC CPU 2017 benchmarks plateaus at around 4-5 independent micro-ops per cycle at realistic memory latencies. Scientific codes with long independent reduction chains can sustain higher ILP, but branch-heavy code (compilers, databases, interpreters) often runs with effective ILP of 2-3. This means a 6-wide machine is frequently stalled waiting for the dependency chain to clear, not constrained by front-end bandwidth. Increasing to 8-wide or 10-wide adds structural cost - a wider register rename stage, a larger instruction queue, more read ports on the register file - without adding throughput on the workloads that are already dependency-limited.
The Structural Scaling Cost
The reorder buffer (ROB) is one of the clearest examples of superlinear area scaling with width. A wider machine needs a larger ROB to keep the execution units busy in the face of memory latency - a 6-wide machine with a 512-entry ROB and an LLC miss latency of 40 cycles needs 240 in-flight instructions to hide the miss; an 8-wide machine with the same latency needs 320 entries. ROB entries are multi-ported SRAM arrays - wider means more ports, which grows area and power faster than linearly with entry count. The register rename stage scales similarly: a 6-wide rename stage needs to read and write 6 register map entries per cycle with no structural hazard; an 8-wide stage requires two additional fully parallel port groups. Apple’s Everest core is estimated (from die area analysis by independent researchers) to dedicate roughly 30-35% of its core area to the out-of-order machinery - ROB, issue queues, rename tables, and load-store queues. Scaling that fraction wider adds area that could alternatively fund a larger L2 cache or more execution units of a specific type.
What Wide Machines Do Well
The cases where width scaling still delivers are front-end bottlenecks that additional decode bandwidth resolves, and workloads with genuinely high ILP - cryptography, signal processing, dense matrix operations without blocking. For server workloads where Amdahl’s law is reversed (many independent threads rather than one deep dependency chain), the trend has moved toward more narrower cores rather than fewer wider ones, as seen in the ARM v1 and v2 Neoverse server cores. The microarchitectural space that remains active is not raw width scaling but improving the efficiency of the out-of-order machinery at current widths: better load-store disambiguation (reducing false memory dependences that serialize issue), smarter memory prefetching to reduce ROB drain, and value prediction to break artificial dependency chains. These techniques improve effective ILP without the structural cost of additional rename ports or wider decode.