AMD balances on power performance tightrope

AMD'S CHUCK MOORE kicked off the Spring Processor Forum with a talk about power and balanced system design. The concept was simple. Power matters, and performance needs to take power into account. System performance used to be about ramping MHz to get performance from a single core. That is no longer the case, there are literally dozens of things to take into account now.

The speed trend is now old news. CPUs got faster and faster, sucked more and more power, and in general, ran dead on into a wall. Because Moore's law gave them more transistors to work with, but faster wasn't the solution. This lead wider, and that to complexity, which grows at a staggeringly fast rate. If you make the CPU wider, the work it takes to accomplish this grows geometrically.

Where do you go? You add features, look into extensions like SSE, VT/Pacifica, and integrated memory controllers. This gets you pretty far, but soon enough, you run into a wall again. The current solution is to add cores, and the next generation answer will be to add cores and cores and cores and cores.

This runs you into another wall, parallelism. If your software is amenable to threading, throwing cores at the problem is a good thing. If you are the other 99.5% of the computing world and your software doesn't play that game, more cores tend to sit there and do little or nothing.

So, what do you do? A little of this, a little of that really. There seems to be no magic bullet, and a clear path on what not to do, ask the Intel Pentium 4 architecture team about that one. Any time you step out of line much, you get hit with the cluestick(1), do not pass Go, do not collect $200.

It all boils down to knowing where you want to go, asking people what they want, and getting there without getting caught in any of the vicious complexity and power slippery slopes. If there is one thing about AMD of late, it is showing a very keen sense of where not to go and when not to do things. It may not be on the cutting edge at all things, but the end result is a system that is 'right' in more ways than several other implementations. µ

(1) A Louisville Slugger with 'Clue' carved in to it.