Re:The Importance of End-to-End Thinking in System Design
by goldcd on Thursday October 22, 2020 @04:28AM
(#24855935)
I'd agree.
When looking at systems, the focus is always on the bottle-necks - what is the component that is throttling the whole system. Which is fine, until you replace the next one, and the next one - and eventually you end up with 'success' - or looking at it another way, "everything is the bottle-neck". At this point you're stuck as you've incrementally worked your way into a corner and can't make large changes.
If in parallel, you'd put a bit of effort (i.e. time/money) into development of components to try to make them optimal/flexible etc in their own right - you've a decent head-start on creating system v2
That is, sometimes isn't it good to over optimize a part to the detriment of the system, so that you can then fix the parts it leaves exposed?
Take the example of the register file in the article, it was bad because they had to route over parts of the chip that had been planned for the file, but were now empty. That said, they now had a better target for how much they had to allocate to the file next time, such that they could use that space or a smaller die.
This is equally true for the example on the wide execution stage. If you can manage to do that without blowing some other budget, then you expose a target that the fetch now needs to be improved.
In a sense, sometimes you can either improve the cart or the horse. Sometimes you can improve both. Often the full system only benefits when you get both to the same level of benefit, but doing both at the same time can be prohibitive. And if you preclude work that can't benefit without other work, then you often starve out ways for that work to happen.