3 ms·

These are all problems that have easy solutions - chuck more CPUs at it. Back in the ideal world though, I would say the harder problem is still not these, it

These are all problems that have easy solutions - chuck more CPUs at it. Back in the ideal world though, I would say the harder problem is still not these, it would be the increased operational complexity. Support and maintenance costs go up. I think the problems are somewhat over played here too. We've had zero copy network stacks for a while. Stack sizes are not a concern because scheduling becomes a bigger problem faster than using small chunks of memory does as you scale. Edit: forgot to mention isolcpus or pinning as one method to solve the context switching - of course frequently we can make greater impact by careful consideration of the syscalls we make from our code.

astrobe_ 12y ago
> These are all problems that have easy solutions - chuck more CPUs at it. So basically you tell us that if your application that uses bubblesort everywhere is too slow we just have to "chuck more CPUs at it"? No Thanks. That line of reasoning makes me angry twice: as an embedded systems engineer (for which that kind of "solution" is simply not an option) and as a user (when I see applications take more and more megabytes and CPU cycles without proportionally increasing functionality).
- CraigJPerry 12y ago
  This, is the way of the world. Don't get angry about it though. Instead make it easier for stakeholders / customers to choose to do "the right thing". Be transparent and accurate with time-to-fix estimates. That's a hard problem, i don't even think it's perfectly solvable but i try hard anyway. The uncomfortable truth - sometimes "the right thing" is to throw more CPU at it. Being late to the consumer electronics market for example, even if your product is bug free and perfectly designed, means you lost a whole chunk of available cash to the guy who got there first... With that money, he may be enabled to make a v2 that completely trumps yours.

astrobe_ 12y ago

> These are all problems that have easy solutions - chuck more CPUs at it. So basically you tell us that if your application that uses bubblesort everywhere is too slow we just have to "chuck more CPUs at it"? No Thanks. That line of reasoning makes me angry twice: as an embedded systems engineer (for which that kind of "solution" is simply not an option) and as a user (when I see applications take more and more megabytes and CPU cycles without proportionally increasing functionality).

CraigJPerry 12y ago
This, is the way of the world. Don't get angry about it though. Instead make it easier for stakeholders / customers to choose to do "the right thing". Be transparent and accurate with time-to-fix estimates. That's a hard problem, i don't even think it's perfectly solvable but i try hard anyway. The uncomfortable truth - sometimes "the right thing" is to throw more CPU at it. Being late to the consumer electronics market for example, even if your product is bug free and perfectly designed, means you lost a whole chunk of available cash to the guy who got there first... With that money, he may be enabled to make a v2 that completely trumps yours.