Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ Go to the Back of the Bus ]   |  When Is 64 Not Two Times 32?  |   [ More of the Same ] >>

Weekly Column

When Is 64 Not Two Times 32?: How AMD 64-bit Processor Technology is About to Triumph Over Intel

Status: [CLOSED]
By Robert X. Cringely

This is my last column for 2002, which means next week I'll be making my predictions for 2003. I suppose I could have put the topic of this week's column in that list, but I think it deserves a column all to itself. I am talking about how Intel is going to be forced by Microsoft to adopt some Advanced MicroDevices (AMD) technology.

There is a pecking order in the PC industry, and Microsoft sits at the top, followed by Intel and then by major PC manufacturers like Dell and HP/Compaq. In this world — the world of manufacturers — the customer is definitely NOT always right, because Microsoft dictates to Intel, which dictates to the big hardware OEMs. Microsoft's power is such that it literally designs the computers we will use two years from now by creating a specification built around where Windows will be at that time. Remember a few years ago when PCs started sporting USB ports, even though there were no USB devices available to buy? Those ports were there because Microsoft said to put them there. This is one way Microsoft controls the computer industry — a way never even addressed by the Department of Justice, which probably didn't know enough to look in that direction.

I wrote last week about Intel and how the company is bobbing and weaving to maintain its control of the microprocessor business at the same time it changes its tune from "the higher the clock speed the more powerful the chip" to some other story closer to reality. This column is, in a way, just an extension of that theme. What it is all about, in fact, is extensions — extensions to the X86 processor standard.

For all the clock speed improvements in the last several years, consumers have been steadily getting less of a performance increase with each Intel processor generation. When Intel introduced the 486 processor, it came with a 100 percent increase in the number of instructions executed per clock cycle compared to the 386 processor that preceded it. When the Pentium came along, it offered a 90 percent increase in instructions per clock cycle. The Pentium Pro had a 40 percent increase in instructions per clock cycle over the Pentium. The Pentium II and III offered only a 20 percent improvement over the Pentium Pro. And the Pentium 4 is worst of all, rated at 10 percent FEWER instructions per clock cycle than the Pentium III. Performance in these processors still goes up as clock speeds increase, but each increase in clock offers less of an increase in performance.

Some engineers take this as just the way of the world, but things happen a little differently over at AMD, where even the latest version of its Athlon processor — the Athlon-64 — doesn't seem to suffer from this performance degradation. That's why AMD can claim that its chips are just as fast as Intel's even if they run at a lower clock speed. Why little AMD gets this right and mighty Intel doesn't probably comes down to the capable engineering of a very small number of people, and maybe only ONE person.

That's the way it is at the leading edge of the chip business. I knew a guy named Rajit, who was at the absolute forefront of asynchronous processor design, an esoteric field that is becoming increasingly important for reducing both size and power consumption of chips. If you are in the asynchronous logic field, you know who Rajit is. He had a knack for the stuff, that's for sure. He understood it in a native way that nobody else did at the time, which made chip design, if not effortless for him, say a thousand times easier than it was for the otherwise equally smart guy down the hall. Rajit was a one-man asynch design lab, and both Intel and Sun wanted very much to hire him, though neither ever did. Both companies were unable or unwilling to provide the kind of motivation Rajit required — cats and chocolate. Most likely, they couldn't even imagine an engineer unmotivated by stock or money, which are the normal currencies of recruitment. Cats and chocolate would have been cheaper, of course, but they didn't bother to learn enough about the guy to know how to attract him. Today Rajit — smart as ever — teaches at Cornell, which must be chockablock with cats and chocolate. Or maybe it has just the normal levels of each and an absence of crazy product deadlines.

Back to the troubles of Intel. Not only are the chips not as fast as they might be, they have often been late to market, and occasionally, haven't made it to market at all. That's the case with Yamhill, a recently cancelled Intel chip that was supposed to add 64-bit instructions to an X86 core. The official line from Intel says Yamhill was cancelled because it might have caused confusion with Intel's other 64-bit chips. The unofficial line says Yamhill was a dog.

While Intel has 64-bit chips in the pipeline, specifically the Itanium, which is the successor to the disappointing 32-bit Xeon, which was the successor to the not-so-bad-but-hardly-a big-success Pentium Pro, the Itanium chips aren't backward compatible with 32-bit applications. That's what Yamhill was supposed to be, and Yamhill is now gone. So maybe Yamhill didn't compete with other Intel chips, after all.

So Itanium is aimed at servers where presumably it is okay to have all 64-bit applications. But what if one of your favorite server applications isn't yet available in a 64-bit version? Worse still, what if that favorite application is an orphan that will NEVER be available in a 64-bit version? Or what if you are a CIO or CTO or CEO or COO, or any other type of C-something-O who doesn't like the idea of committing his or her entire information infrastructure to new and so-far unproven 64-bit software? That describes just about any IT leader in a period of economic (and therefore job) uncertainty.

While Intel has made this bold commitment to 64-bit computing, AMD took a different course, making its Athlon-64 (workstations) and Opteron (server) chips compatible with both 32-bit and 64-bit applications, just as Intel's Yamhill was supposed to do. And where Intel was unable to make their dual-mode chip run fast enough in both modes, that is apparently no problem for the two AMD chips, which are screamers.

Now Intel still has tremendous clout with computer manufacturers, so this momentary superiority of AMD silicon doesn't, in itself, mean that all the big companies are going to drop Intel for AMD, or even that they are going to use AMD in addition to Intel. No, it is going to play out very differently from that.

Remember that PC pecking order? It placed only Microsoft above Intel. And Microsoft, it turns out, is extremely wary of Intel's current 64-bit product plan. Microsoft, too, doesn't want to commit completely to 64-bits, in part because they have a lot of software to upgrade and can't get it all done soon. So Microsoft likes a dual-mode chip. They liked Yamhill until it died. Microsoft likes Athlon-64 and Opteron A LOT — enough to have worked with AMD (and only AMD) to make a 64-bit version of Windows that works in 64-bit mode only with AMD processors.

To do this, Microsoft has written Windows to AMD's 64-bit extensions, which are new instructions added to the X86 instruction set to allow the chip to work either way.

Microsoft is not proposing that computer companies abandon Intel, because its Intel relationship is too important and AMD is too small to be relied upon as a sole supplier. So what is likely to happen (here comes my prediction) is that Intel will be forced by Microsoft to adopt AMD's 64-bit instructions. To do this they will build a processor by the end of 2003 that is a clone of an AMD processor that is a clone of an Intel processor. Say that four times quickly.

Comments from the Tribe

Status: [CLOSED] read all comments (0)