Yes, exactly. I didn't describe this but it's something I was thinking about: if you don't hit the bottleneck, you don't pay any price: if the limit of uops all

Yes, exactly. I didn't describe this but it's something I was thinking about: if you don't hit the bottleneck, you don't pay any price: if the limit of uops allocated is 4 but you are only doing 3.5, you don't pay any price: the limit might as well be infinite. It's for this reason I struggled to include, for example, branch prediction failures. Let's say they take a 15 cycle bubble in the front-end. You can create a "speed limit" there and say "you can't do more than 1/15 mispredicts per cycle", which is indeed true. However, it then doesn't work like the other limits: if you measure 1 mispredict every 30 cycles, you aren't at the limit, but it still has a huge impact on performance, because the bubbles are likely slowing down everything else you do in those 30 cycles too. Perhaps 15 cycles of the 30 are solely dedicated to handling the mispredicts. Therefore to include mispredicts here, it won't be a simple "speed limit" thing: you will need to understand the exact effect of the mispredict on the front end, and how it interacts with the other speed limits. Sometimes a mispredict costs 15 cycles (the figure you hear), but sometimes they don't slow down your code at all, and you can certainly design tests where they cost 1000s of cycles each.