3 ms·

I love approaches like this: instead of butting your head against the same limits, look at the whole problem, find a re-frame the problem with a new trade-off t

by 6ren 13y ago

I love approaches like this: instead of butting your head against the same limits, look at the whole problem, find a re-frame the problem with a new trade-off that actually the whole problem. Arguably, this is what Clayton Christensen is talking about with "over-shooting": making your product better than it needs to be in some particular dimension, just because that's the way you've always been making it better. But like doing your shopping in a Ferrari, maybe increased horsepower isn't what's really needed. Here, they'll saying that bursty usage (they call it "sprinting") is what is actually needed. I noted this with word-processors - most of the time the PC is idle - and wondered how those cycles could be harnessed. Instead, they say, turn it off. This might be an alternative to many-core - just boost it x100 faster. It can also go the other way, having a much less powerful processor, just super-boosted for when needed. Cheetah would be a good code name for this project.

nknighthb 13y ago
It doesn't solve "the whole problem". It won't help with any sort of batch processing, nor with the latest game trying to squeeze every bit of performance out of the hardware. Worse, it may actually encourage bad behavior by applications. We already have problems with applications draining batteries unreasonably fast on mobile devices because they implement features in ways that look "fast enough" interactively, but under the hood are an unnecessary power drain. Now such inefficiencies can be even less obvious! There's a lot more to practical application of this than tossing some wax on a chip.
- 6ren 13y ago
  The "whole problem" doesn't mean "every problem". It means taking a step back and seeing what the user is really trying to accomplish, and everything that is needed for that problem to be solved - as opposed to myopically seeing just one aspect of that problem. Some extreme examples of whole solutions: Edison establishing a power generator and power line infrastructure, not just a light bulb (Musk's Tesla is doing similar now); Birdseye establishing freezers in supermarkets, not just selling frozen fish. Sometimes, you'll focus on one specific user problem, which can even mean removing features. BTW: I'm taking the term from Crossing the Chasm (Geoffrey Moore). Of course, what you say is true about continuous loads, and also battery drainage for bursty loads. It's not a solution to every usage pattern, and as the article mentions, it's around 10 years away. I love changing problems to see unexpected ways of solving them - even if it does take years to realise the vision.

by 6ren 13y ago

nknighthb 13y ago

It doesn't solve "the whole problem". It won't help with any sort of batch processing, nor with the latest game trying to squeeze every bit of performance out of the hardware. Worse, it may actually encourage bad behavior by applications. We already have problems with applications draining batteries unreasonably fast on mobile devices because they implement features in ways that look "fast enough" interactively, but under the hood are an unnecessary power drain. Now such inefficiencies can be even less obvious! There's a lot more to practical application of this than tossing some wax on a chip.

6ren 13y ago
The "whole problem" doesn't mean "every problem". It means taking a step back and seeing what the user is really trying to accomplish, and everything that is needed for that problem to be solved - as opposed to myopically seeing just one aspect of that problem. Some extreme examples of whole solutions: Edison establishing a power generator and power line infrastructure, not just a light bulb (Musk's Tesla is doing similar now); Birdseye establishing freezers in supermarkets, not just selling frozen fish. Sometimes, you'll focus on one specific user problem, which can even mean removing features. BTW: I'm taking the term from Crossing the Chasm (Geoffrey Moore). Of course, what you say is true about continuous loads, and also battery drainage for bursty loads. It's not a solution to every usage pattern, and as the article mentions, it's around 10 years away. I love changing problems to see unexpected ways of solving them - even if it does take years to realise the vision.