You've seen the bypass network problem: every execution unit needs to forward results to every other unit's inputs, and wire count grows as O(N²) with issue width. At 4-wide issue it's manageable. At 8-wide it's a nightmare. At 16-wide it's physically impossible at high clock frequencies — the wires can't make it across the die in one cycle.

The solution adopted by aggressive wide designs (Alpha 21264, AMD Zen, Apple's M-series) is execution clustering: partition the execution units into two or more clusters, each with its own local register file copy and full intra-cluster bypass. Cross-cluster forwarding costs an extra cycle of latency, but intra-cluster forwarding stays single-cycle.

The Alpha 21264 is the canonical example. It had 4 integer ALUs split into two clusters of 2. Each cluster had a full copy of the 80-entry integer physical register file. Writes to either cluster had to propagate to both copies — a 1-cycle delay. An instruction in cluster 0 consuming a result produced in cluster 1 paid that extra cycle. The scheduler's job became not just when to issue but where — picking the cluster that minimized cross-cluster traffic.

The wiring math: A monolithic 8-wide execution core needs roughly 8 × 8 = 64 forwarding paths, each carrying a 64-bit result plus tag. Split it into two 4-wide clusters and intra-cluster wiring drops to 2 × (4 × 4) = 32 paths, plus a much narrower cross-cluster bus. You've roughly halved the wire count and — more importantly — cut the longest wire length, which is what actually limits clock frequency.

The cost shows up in the steering heuristic. Apple's M-series and AMD Zen 4 both use clustered integer execution. Their schedulers prefer to keep dependent instruction chains in the same cluster. When a load result is needed by an ALU op, the steering logic tries to place the ALU op in the cluster nearest the load unit. Get it wrong and you eat a cycle of cross-cluster latency on the critical path.

Rule of thumb: below 6-wide issue, clustering rarely pays — the wiring is tractable and steering overhead exceeds the savings. Above 8-wide, clustering is essentially mandatory unless you're willing to drop clock frequency significantly. The crossover point keeps creeping wider as process nodes shrink wire delays slower than gate delays.

You can sometimes see this in microbenchmarks: chains of dependent integer ops will show consistent latency, but introducing a memory dependency or mixing in a multiplier (often in its own cluster) can add a mysterious cycle that disappears when you reorder the code.