Newsmaker: AMD hits its stride

Chipmaker Advanced Micro Devices often attempts to make up whatever it might lack in size with a pragmatic approach toward its competition against bigger rival Intel.

But that doesn't mean AMD can be dismissed as an also-ran, according to company CTO Fred Weber. In fact, over the last few years, the PC industry, including Intel, has followed AMD in making the transition from 32-bit software to 64-bit software. Weber recently spoke with CNET News.com about how that transition is forcing changes in hardware, as well as the technology race with Intel.

Q: Are AMD and Intel now seen as peers? Do you think AMD's technology is better?
A: I think we were seen as the little brother and the one who had more challenges. No question about that. But I think we are now given the respect of being a legitimate player in that market. That's very gratifying, and it sets the stage for us to do a lot more. In some sense, you can do more when the expectations on you are higher.

I must admit I think we have better (processor) architectural taste.

You asked whether we think our technology is better? I guess I would say yes. It'd be a hard question to say no to, wouldn't it?...I think we have some important technology leads, but Intel is a great innovator as well. The most important thing about our technological approach again is it is a systems-oriented approach and a customer-centric approach.

What does that mean in practice?
Intel talks a lot about their platform approach and Centrino, and so on. Give them some credit for doing that more and more. To me, it sometimes rings a little bit hollow. Many of the things still seem to have a heritage of a chip company and a dominant player who may develop a platform, but they pretty much force that platform on you whether it's the right one or not.

What sets you apart from Intel?
They have the advantage of size, and that lets them innovate. We have the advantage, in some sense, of lack of size that lets us innovate. I must admit I think we have better (processor) architectural taste.

Can you give us any examples of where you're looking next?
Look at what we are doing with our Geode line of processors, where we've got system-on-a-chip based designs. These are devices that use average power for the entire system of a watt and less. Still, they give PC-performance experiences, and run Windows XP and other operating systems. They're much slower devices than a 3GHz desktop PC--they might be 400MHz, 500MHz--but that's all the

More Newsmakers

[Andrew J Glina]

Buy now pay later

The AMD vs. Intel CPU war is always interesting. Even so, from the point of view of an assembly language programmer, it is a disappointment that AMDs 32/64 bit push appears to be winning. 64 bit personal computing, while unquestionably desirable, is not needed now and it probably would have been better to wait until the Itanium's price came down and the average system memory size was 2GB. (I have 256 MB and run Win2K.) Intel's pure 64 bit model would of produced better programs due to the elimination of 20 years of legacy support, but it is becoming increasing likely that the Itanium may never become a dominant consumer CPU. It was my hope that the 64 bit change would go smoother and be more distinct than the 32 bit one. The 80386 was the Intel?s first 32 bit chip and it came out in 1985. However it took 15 years until a mainstream OS came out that was fully 32 bit, and even now 16 bit software is still around. Will we now see a repeat with the 64 bit systems?

One of the biggest limitations of the x86 family is the low availability of usable general purpose registers. Registers are small areas on a chip that are used for short term storage and data manipulation. A high numbers of registers reduces the CPUs reliance on memory (including cache) which massively increases CPU efficiency. The Itanium has 128 General Purpose Registers, the PowerPC (In Macs) has 32, and x86 chips have 8. Much of the AMD64 increased efficiency of recompiled code is due to changing of memory access to registers. AMD64 chips double the amount (from 8 to 16) and size of the registers (from 32 the 64 bit), but they need to have a prefix prior to each 64 bit instruction so the CPU knows to treat the instruction. This contributes to why recompiled code is around 25% bigger than the 32 bit equivalent. It seems silly to me to be stuck with this problem permanently even if the whole world migrates to 64 bit computing and uses no 32 bit software. Besides, the current generation isn?t much faster than Athlon XP processors of similar MHz unless run on a AMD64 OS using AMD64 optimized software.

The AMD64 (and their Intel clones) are not the revolutionary chips that many hail them to be, but they definitely are an improvement. Opterons especially excel in the multi-processor server market due their HyperTransport bus. The core design of the x86 dates back to the mid 1970s so why add another patch to an already over patched design? Eventually the mainstream computer world will have to make a clean break with the past, so why not now? It does make me wonder why the PC world can't pull off the same change as Apple did when they dumped 68000 processors and upgraded to PowerPCs. It was not without its fair share of problems, but in the end it was worth it.

(I will probably buy mine next year after the Windows XP 64 bit non-beta version is out. If you can't beat 'em...)

[billtodd]

The difference between theory and practice

is important here. Let's examine your points one by one:

"from the point of view of an assembly language programmer, it is a disappointment that AMDs 32/64 bit push appears to be winning."

And it's not *all* that much of an exaggeration to suggest that the number of people around the world so disappointed could all congregate in a single medium-to-large restaurant some evening and commiserate about it. I.e., that disappointment, such as it may be, is not really significant (and I say that as someone with a decade of professional experience doing nothing *but* assembly language programming).

"64 bit personal computing, while unquestionably desirable, is not needed now and it probably would have been better to wait until the Itanium's price came down and the average system memory size was 2GB."

Only if one accepts that Itanium would have been a preferable platform, which I'll address below. Otherwise, sooner is better, if for no other reason than that it gives developers the inexpensive platforms they need to generate the 64-bit application base which desktops will want to have by the time they'll want to have it (and of course *some* non-developers will be able to profit from it earlier as well - e.g., those heavily into graphics and video - plus Windows itself has some operating system bottlenecks which a 64-bit platform eliminates, even when all the user applications remain 32-bit ones).

"Intel's pure 64 bit model would of produced better programs due to the elimination of 20 years of legacy support"

That's a very debatable assertion. Despite being a new architecture, Intel and HP managed to trowel a fair amount of native cruft into Itanium (Alpha users porting there experience a 3-fold increase in code size, for example - and Alpha code is already somewhat less dense than x86 code).

"It was my hope that the 64 bit change would go smoother and be more distinct than the 32 bit one."

What you see as desirable, others do not.

"The 80386 was the Intel?s first 32 bit chip and it came out in 1985. However it took 15 years until a mainstream OS came out that was fully 32 bit, and even now 16 bit software is still around. Will we now see a repeat with the 64 bit systems?"

One might hope so. There's no earthly reason why the vast majority of existing 32-bit programs should *ever* need to be ported to 64 bits, as long as the available processors continue to run them at full speed. And, of course, there are a few hundred million people around the world with existing copies of these programs who would just as soon be able to continue to run them.

"One of the biggest limitations of the x86 family is the low availability of usable general purpose registers."

Fortunately, this 'limitation' is of interest only to theoreticians and to designers of compiler back-ends (which must generate machine instructions from the higher-level language input). Everyone else just cares about how the machine runs, and x86 code runs quite competitively indeed with Itanium code.

"Registers are small areas on a chip that are used for short term storage and data manipulation. A high numbers of registers reduces the CPUs reliance on memory (including cache) which massively increases CPU efficiency."

Well, no, it doesn't - because registers (at least in the role you're ascribing to them) simply constitute yet another level of cache (the term 'level 0' is sometimes used). So having more registers is only one way to skin the performance cat: having a very fast level-1 cache is another, and having a lot of extra 'invisible' internal registers (used by a mechanism called 'register renaming') effectively increases the size of the 'level 0' register cache without making those additional registers externally visible.

So massive numbers of registers (especially visible registers) fall much more into the 'nice to have' category than being anything resembling a feature of 'massive' significance. The proof is the performance-competitiveness of the x86 architecture with both its Itanium and RISC competition.

"AMD64 chips double the amount (from 8 to 16) and size of the registers (from 32 the 64 bit), but they need to have a prefix prior to each 64 bit instruction so the CPU knows to treat the instruction. This contributes to why recompiled code is around 25% bigger than the 32 bit equivalent. It seems silly to me to be stuck with this problem permanently even if the whole world migrates to 64 bit computing and uses no 32 bit software."

Hmmm. Doesn't it seem even sillier, then, to be stuck with something like a the *4-fold* across-the-board increase in code size implied by the Itanium architecture?

"Besides, the current generation isn?t much faster than Athlon XP processors of similar MHz unless run on a AMD64 OS using AMD64 optimized software."

But it runs existing software *vastly* faster than Itanium does - in fact, about as fast as Itanium runs 64-bit software.

"The AMD64 (and their Intel clones) are not the revolutionary chips that many hail them to be, but they definitely are an improvement."

Given that they open the door to 64-bit computing without closing it on the existing 32-bit environment, while at the same time providing performance that no other architecture can beat (we are talking about cores here, not all the ancillary aspects like busses, memory paths, etc.), one might suggest that they're a very significant improvement.

"The core design of the x86 dates back to the mid 1970s so why add another patch to an already over patched design?"

Primarily to maintain compatibility with the tremendous existing base of software. IBM seems to have found this desirable in the mainframe environment which was predicted to have died decades ago: its current mainframes can (and do) still run some software written in the 1960s.

"Eventually the mainstream computer world will have to make a clean break with the past"

Care to explain why? If anything, technology advances make the expense of maintaining compatibility less and less onerous.

"It does make me wonder why the PC world can't pull off the same change as Apple did when they dumped 68000 processors and upgraded to PowerPCs."

It's not that it can't do that, it's that it has no need to.

"It was not without its fair share of problems, but in the end it was worth it."

And today it would not be.

- bill