EET: What about the Opteron processor? For servers, is Opteron going to change much?

Hester: When we look at the server side of things, we are starting to see a pretty broad mix of application types, some of them based on Java and XML. We are looking at whether there are instruction-set extensions that could provide a 2x or 3x boost. We have to decide if that is a good use of silicon. Now we are looking at the workloads, what the characteristics are, what things you can do at the microarchitecture and instruction set [levels].

Generally, 80 percent of the benefit from 20 percent of the silicon is a good trade. In some cases there clearly is an advantage to an attached coprocessor. We want to make it easier for people to attach a coprocessor to the coherent HyperTransport link. The options might include Java, XML, vector floating-point units or any attached processor that needs very high bandwidth and that also needs to deal with coherency. There are some problems with it. Nowadays we have JIT [just-in-time] compilers, and once you do it in silicon you are kind of stuck. We have to hit the right balance between what you do in hardware and what you do in the compiler. I don't think it ever goes as far as an XML engine in hardware.

EET: As we scale to 65, 45, 32 nanometers and so on, are we going to see big performance boosts in the processors?

Hester: It comes back to how you want to spend the power. If you had a way to understand the characteristics of the application better, then you could think about things like powering off the cores that were not being used, and raising the voltages and clock rates of the one or two cores that were effectively being used by those threads. We could accomplish a lot more internal variation of performance and clock rate across these cores, to better optimize the structure of the hardware to the characteristics of the software. That's more of a three- to five-year sort of discussion.

If you just think in traditional ways about every core running at the same clock rate, I don't think you will see a lot of performance improvement. If you had a way to vary the voltages and clock rates of individual cores, you could see some pretty nice performance improvements.

Shutting down a core is not hard, but you want to be able to do it fairly quickly, with instant on. You need to go from extremely low power, come out of that quickly and preserve the execution environment. That has to happen within a second, so it is on when the user pushes the button. That is under active research right now. If you did it right, the only thing that would change is the BIOS.

EET: What about security?

Hester: We'll have to see what develops this year for digital rights management. If a consensus builds around DRM virtualization, we could see more of that embedded three or four years from now.

In the server space, it is pretty common to see multiple servers on a common platform. In the client space, we can use virtualization to build a secure environment, a sandbox, so that if something goes wrong — say, a virus — then that virus could be contained on that virtual machine. With the right hardware/software interface, we could restart the system from the prior checkpoint if the PC were to become infected.

EET: What's it like working at AMD, compared with your previous CTO job at IBM?

Hester: AMD has always been the underdog, so it has a very collaborative culture. We use videoconferencing a lot. We have an eight-foot-wide conference table, and on the other side are a series of life-size flat panels. Eight people can share documents, and the resolution is so good that you can see the facial expressions and get the nuances. Some of our partners have it [too], and that has helped quite a bit. n

Phil Hester

Born:
April 30, 1955, Corpus Christi, Texas

Education:
University of Texas at Austin, BSEE, 1976; MS, engineering, 1981

Current position:
CTO, Advanced Micro Devices Inc.

Previous jobs: