It’s tough to equate data centers with low power, but some of the biggest savings in power are coming from places that are the biggest consumers.

For mobile users, having a device that consumes less power is a convenience. The battery lasts longer between recharges, and the overall life of the battery and its ability to hold a charge is increased because it needs to be charged less often. In a data center, though, it’s not a convenience. It’s business.

In large companies—those with tens of thousands of employees—the costs for running servers, power supplies and for cooling racks of very hot servers can run millions of dollars per year.

While most applications still can’t be multithreaded across many different cores, they can be virtualized. Performance is less of an issue for many applications these days than the cost of power, so multicore machines work extremely well for consolidating many applications and operating systems (running on separate virtual machines) onto a single multicore server.

This isn’t a one-to-one mapping, of course. You don’t just add cores and run more applications. The bus needs to be widened, memory needs to be reconfigured, and there needs to be a prioritization of what applications get access to what resources on those chips. But the savings that can be achieved by boosting the utilization of servers and reducing the number of machines needed to run applications is immense.

The same is true in the automotive industry. While saving mileage on a car is great for car owners, it’s the trucking industry—the vehicles that are on the road all the time—that has the most to gain from more efficient electronics and motor technology.

Over the next decade, virtually everything we know will be re-engineered, and for the first time power will be an integral component of that re-engineering. In some cases, it will be the cause. And taken as a whole, it should spur one of the biggest development booms in electronics history.

So far, we’ve only scratched the surface.

–Ed Sperling

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

There have been many predictions about just how important software will become over the next decade. The simple truth is that while the software used to create hardware has made great strides, the applications running on the hardware have not. For the better part of three decades, hardware engineers have been bailing out these applications developers.

Apps developers add the functionality, hardware engineers make it work. Apps developers add bloat, hardware engineers compensate for it and speed it up. Apps developers create more features, hardware engineers figure out ways to time them so they work properly.

The problem now is that hardware engineers are running out of tricks. The power budget has made scaling extremely difficult, except with multiple cores, and so far it doesn’t look as if much of the software will be able to use more than a couple cores. In fact, the real contribution may come from real-time operating systems and hardware accelerators, rather than the applications.

While it’s true that chipmakers are hiring more software engineers than hardware engineers these days, they’re not hiring applications engineers. And it’s the apps engineers who are falling down on the job, if indeed the job can be done at all. There’s plenty of need for multithreaded, parallelized software applications, and so far there aren’t a whole lot of them.

Virtualization can help take advantage of multiple cores, but it does nothing for speeding up performance or reducing the amount of power used by applications. And one application per core can cause timing nightmares if there are several in use at the same time, not to mention drain the battery because of the overhead needed to manage them.

It may be time for chipmakers to start thinking through the software conundrum and how to make software run more efficiently. After decades of letting the apps developers handle it, they haven’t gotten very far.

–Ed Sperling