Co-Developing Killer Apps
The growing complexity of hardware is taking its toll on the application software development world.
While most hardware engineers think in terms of embedded applications, the real problem is in other parts of the software stack. The operating system still cannot take advantage of multiple power islands and other tricks used to save power, and many software applications still cannot take advantage of more than a couple cores.
That explains why Intel bought Wind River earlier this year and why Cavium networks just announced a deal to buy MontaVista Software, which makes embedded Linux. Both are a result of the same problem. Full operating systems can’t be modified fast enough to take advantage of the number of processor cores in chips or to utilize a core that offers just enough performance for a specific task at far less power.
There are several trends under way here. First, processing on a chip is shifting from synchronous to asynchronous. That means all the pieces or cores will work off the same power supply or necessarily at the same voltage. But it does free them up to run different software.
Second, multicore architectures are moving from homogeneous to heterogeneous—different sizes, different power needs and different software. Some may run executable functions rather than full applications, and some may use different operating systems.
Third, programmability of the cores and the software running on them will become a major plus—particularly in the low-power world—because it will be easier to verify and to adapt to different voltages, cores and software stacks.
All of these changes will also put a bigger burden on chip engineering teams. Over the next couple nodes they’re going to be called upon to do much more of the software development than in the past because they understand the way it can leverage the hardware. And the software engineers working alongside them as part of their team are going to be writing much more than ever before.
We’re entering a new phase where complexity is forcing convergence and flexibility, and the number of people who understand how to leverage it for both power, performance and cost needs to grow dramatically to make this all work.
–Ed Sperling
December 10th, 2009 at 5:09 pm
Here’s the real problem:
For at least four decades, following Moore’s law, computer manufacturers have made their machines exponentially faster with more memory, since it’s about the only way to differentiate a product that has so little to do with the real world that the only way to tell it’s running is to check the fan or power light.
Programmers don’t make code smaller unless it’s too big, and they don’t make it faster unless it’s too slow. It’s simple economics. The result is forty years of exponentially increasingly bad code. Even bright, well trained, experienced programmers find themselves swimming in septic tanks trying to glue the refuse together with spit, rather than productively providing software solutions, as well as why the most successful OS vendor has to update my software most every Tuesday.
It’s the most significant factor in the state of the industry, and it certainly helps to explain why programmers have no idea what parts of the circuitry are in use.
I only blame myself. I should have stopped the process somehow. I feel like Charlton Heston in “The Towering Inferno” looking up at the smoldering behemoth and stating “We never should have built them this tall…” On the bright side, there’s usually no software in tube-based guitar amps.