Love the story, though the examples feel off to me. For many, it is just highlighting that at the full system level, performance and features are effectively a game of whack-a-mole.
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.
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
I think a more concrete way to think about this is to walk through scenarios of design to their end conclusion and beyond and then assess every variation and possible iterations or issues in your mind before getting down to implementation. End to end systems design works best when you think about the solution and constantly rotate through a feedback loop in your brain about how to execute on it. That's my thoughts anyway.
The problem with this is that most systems designers think "end to end" means the data flow through a system from input to consumption and they're done. A huge majority of them fail to consider things like building, testing, deployment, environment configuration, scalability, maintenance, monitoring, disaster recovery, geo-replication, prevention of workflow bottlenecks and the n-thousand tiny pieces of the puzzle that go into ensuring systems function adequately and don't pertain specifically to the data they're trying to capture and utilize.
Unfortunately I think this is a limitation of experience. I personally started by racking servers, doing desktop support and similar before moving on to system administration, programming etc. Having the ground up understanding especially when you're supporting sales people for an end user product gives you great insights into the entire pipeline and flow of the system. Experiencing similar things at the juggernaut that as Google its hard not to end up with this sort of end to end understanding. I'm not sure how you give it to people in practice without actually making them do the work and go through all these stages or to at least be part of that process.
On a more personal level, I have always enjoyed building things from nothing whether it be bikes, PCs, systems. So it might also just be a personality thing, where deconstruction and building for an end user experience matters.
8 comments
[ 1.6 ms ] story [ 13.9 ms ] threadThat 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.
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
On a more personal level, I have always enjoyed building things from nothing whether it be bikes, PCs, systems. So it might also just be a personality thing, where deconstruction and building for an end user experience matters.
But the specific examples were too specific. They require too much background information to understand.