I generally dislike the "bottleneck" metaphor when applied to performance, because the metaphor only makes sense when the individual "parts" run in parallel. In most scenarios, each bit of code adds its own latency that is independent of the latency of other components. So every component is a "bottleneck", so-to-speak, it's just that some are bigger bottlenecks than others.
However this case is an unusual exception, because all of these hardware components described in this article do run in parallel. So the slowest element does truly gate the throughput of all stages of the pipeline. You could add more load to the non-bottlenecked resources and the overall latency of the pipeline wouldn't change at all, roughly speaking.
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.
However this case is an unusual exception, because all of these hardware components described in this article do run in parallel. So the slowest element does truly gate the throughput of all stages of the pipeline. You could add more load to the non-bottlenecked resources and the overall latency of the pipeline wouldn't change at all, roughly speaking.