x86-64 vs. Itanium

[Athlon4all]

I hope this is technical enough for this forum. I am wondering if someone can explain what really is the difference between IA64 and x86-64 in terms of functionialty and performance? Is x86-64 a fullly capable 64-bit processor, but simply slower than IA64 because of IA64's EPIC Architechure? Or is x86-64 simply a limited 64-bit CPU? If this isn't "technical" enough for this forums thats fine, I'll ask it in GH. Thanks!

 

[andreasl]

The first step to understanding these differences would be to sort out the definitions properly.

1) IA64 and x86-64 are ISA's (Instruction Set Architecture) defined in documents and specifications (visit www.x86-64.org)
2) RISC, CISC, EPIC are all design philosophies of ISA's.
3) Itanium (Merced) and Hammer are physical implementations of ISA's (ie CPU's).

The bitness of a CPU is determined by how much RAM it can adress. 32-bit CPU's can adress up to 4GB of RAM while 64-bit CPU's can adress much more (I'm lazy to look up the exact number. Type in 2^64 into your calculator...). Now actual 64-bit CPU's are generally limited to being able to adress about 44-54 bits or so.

64-bit CPU's are also able to operate on 64-bit Integers. This is the reason for the expanded registers in x86-64 (from 32-bits to 64-bits). However these are rarely needed in computing and when used they can actually slow down the CPU. This is because they take up twice the space in the code (thus reducing hit-rate in caches) and consuming more FSB bandwidth. 64-bit floats are already implemented in 32-bit CPU's. In fact IA32 can operate on 80-bit floats for extra precision. Because of this, x86-64 does meet all qualifications for a 64-bit ISA. And Hammer is indeed a 64-bit CPU.

The speed of a CPU is hardly dependant on the ISA it uses anymore, but more of the design decitions that went into the CPU during development. But I'll let more qualified guys expand on that.

I hope this explains it.

 

[Locutus4657]

Actually the "bitness" of a CPU is designated by the bit width of its internal registers, not by how much memory it can address. In most normal cases an N bit CPU will be able to address N bits of memory, but this is not always true. For instance Intels Pentium line (since PIII) and AMD's Athlon line can each address up to 36 bits of memory (64GB), yet neither are 36 bit CPUs. The rest of what you said was pretty much accurate though. One think that should be addressed, Itnaic is not nessesarly going to be a faster CPU that Hammer. Since Hammer hasn't been released yet all anyone can do is speculate, however Hammer may very well be faster than Itanic, or slower who knows... Don't assume that just because Intel is makeing the chip that it must be faster, just look at the Athlon line!



<< The first step to understanding these differences would be to sort out the definitions properly.

1) IA64 and x86-64 are ISA's (Instruction Set Architecture) defined in documents and specifications (visit www.x86-64.org)
2) RISC, CISC, EPIC are all design philosophies of ISA's.
3) Itanium (Merced) and Hammer are physical implementations of ISA's (ie CPU's).

The bitness of a CPU is determined by how much RAM it can adress. 32-bit CPU's can adress up to 4GB of RAM while 64-bit CPU's can adress much more (I'm lazy to look up the exact number. Type in 2^64 into your calculator...). Now actual 64-bit CPU's are generally limited to being able to adress about 44-54 bits or so.

64-bit CPU's are also able to operate on 64-bit Integers. This is the reason for the expanded registers in x86-64 (from 32-bits to 64-bits). However these are rarely needed in computing and when used they can actually slow down the CPU. This is because they take up twice the space in the code (thus reducing hit-rate in caches) and consuming more FSB bandwidth. 64-bit floats are already implemented in 32-bit CPU's. In fact IA32 can operate on 80-bit floats for extra precision. Because of this, x86-64 does meet all qualifications for a 64-bit ISA. And Hammer is indeed a 64-bit CPU.

The speed of a CPU is hardly dependant on the ISA it uses anymore, but more of the design decitions that went into the CPU during development. But I'll let more qualified guys expand on that.

I hope this explains it. >>

 

[andreasl]

<< Actually the "bitness" of a CPU is designated by the bit width of its internal registers, not by how much memory it can address. >>



In that case all Intel CPU's since the P3 could be considered 128-bit due to the SSE registers and all CPU's since P1-MMX considered 64-bit due to the MMX registers. Which is obviously completely misleading. Graphic companies use these marketing tactics to sell their chipsets as 128-bit or even 256-bit. But its just a marketing ploy. The most important feature of a 64-bit CPU is being able to adress memory with 64 bits.



<< For instance Intels Pentium line (since PIII) and AMD's Athlon line can each address up to 36 bits of memory (64GB), yet neither are 36 bit CPUs. >>



Actually the 36-bit adress extension was introduced with the Pentium Pro. But it doesn't allow flat 36-bit adressing which is why it's not called a 36-bit CPU.

 

[Duck0fD3ath]

To put it more simply, IA64 is a relatively complex new CPU design, x86-64 is an improvement/extension of the x86 Athlon architecture. Expect x86-64 to run 32bit code faster b/c it can do it natively, while IA64 will have to emulate it (to the best of my knowledge at this point). As for 64bit code, that will have to wait and see, but I'll go out a limb here and speculate that x86-64 will be more scalable clockspeed-wise and will start at higher clockspeeds than IA64. Reports suggest that IA64 has trouble reaching just 1GHz. x86-64 may do to IA64 what P4 has done to Athlon in the performance arena - beat it with clockspeed.

 

[Nothinman]

IA-64 is so dependent on good compiler's it'll probably be a while before we see wide spread, good use of it. There's already full distributions of Linux compiled and running on it, but I doubt they're very impressive since gcc support for IA-64 is still early.

Reports suggest that IA64 has trouble reaching just 1GHz

Funny you say 'just 1Ghz', when the 'heavy hitter chips' like Compaq Alpha and Sun UltraSparc are just now getting to 1Ghz themselves and noone really minds the lower clockspeeds.

 

[Duck0fD3ath]

<< Funny you say 'just 1Ghz', when the 'heavy hitter chips' like Compaq Alpha and Sun UltraSparc are just now getting to 1Ghz themselves and noone really minds the lower clockspeeds. >>



True. I suppose I'm just used to thinking in terms of Pentium 4 Xeons.

 

[Duck0fD3ath]

Here's a good writeup on the differences at Extremetech:

http://www.extremetech.com/article/0,3396,s=1005&a=22731,00.asp

 

[Locutus4657]

SEE/MMX are speacialized SIMD regesters which are not fully general porpouse, there for do not affect the "bitness" of the CPU.



<<

<< Actually the "bitness" of a CPU is designated by the bit width of its internal registers, not by how much memory it can address. >>



In that case all Intel CPU's since the P3 could be considered 128-bit due to the SSE registers and all CPU's since P1-MMX considered 64-bit due to the MMX registers. Which is obviously completely misleading. Graphic companies use these marketing tactics to sell their chipsets as 128-bit or even 256-bit. But its just a marketing ploy. The most important feature of a 64-bit CPU is being able to adress memory with 64 bits.



<< For instance Intels Pentium line (since PIII) and AMD's Athlon line can each address up to 36 bits of memory (64GB), yet neither are 36 bit CPUs. >>



Actually the 36-bit adress extension was introduced with the Pentium Pro. But it doesn't allow flat 36-bit adressing which is why it's not called a 36-bit CPU. >>

 

[pm]

What exactly defines the bitness of a CPU has been debated for a long time. There are exceptions to each definition. I have yet to hear one that everyone agrees upon.



<< To put it more simply, IA64 is a relatively complex new CPU design, x86-64 is an improvement/extension of the x86 Athlon architecture. >>

x86 is one of the most complex ISA's that I can think of. With all of the backwards compatibility and strange things like self-modifying code, all of the addressing modes and other assorted quirks, I can't think of anything that comes close in terms of complexity. IA64 is an entirely new ISA that is designed to move complexity (like BTB's) off chip to the compiler. Although the two implementations of the ISA are large, high-end designs, the ISA is actually fairly straightforward.

<< Expect x86-64 to run 32bit code faster b/c it can do it natively, while IA64 will have to emulate it (to the best of my knowledge at this point). >>

IA64 as an ISA has no knowledge of IA32. The two current microarchitectural implementations of the IA64 architecture have fully-backwards compatible built-in hardware support for 32-bit apps, and can actually boot 16-bit DOS if you so desire. These designs are not exactly speed demons compared with consumer oriented IA32 CPU's, but that's a design choice, not a limitation of the ISA.

<< As for 64bit code, that will have to wait and see, but I'll go out a limb here and speculate that x86-64 will be more scalable clockspeed-wise and will start at higher clockspeeds than IA64. >>

That's an interesting supposition and I'm curious on what you base it on. Clock frequency is practically completely independent of every instruction set that I can think of. If you want to clock it quickly, you can by simply putting more latches in the pipeline. IA64 should, in theory, allow longer pipelines by improving branch prediction through the use of predication and branch hints. Since branch prediction is one of the biggest issues that face long pipeline designs, there should be no reason why IA64 couldn't extend to longer pipelines than IA32. It's a design choice currently to minimize the pipeline to improve IPC. In addition, instruction decoding in IA32 CPU is quite complex and requires a significant amount of the pipeline. IA64 instruction decode is less complex and should require less circuitry to execute, so pipeline stages should be able to be optimized out.

<< Reports suggest that IA64 has trouble reaching just 1GHz. x86-64 may do to IA64 what P4 has done to Athlon in the performance arena - beat it with clockspeed. >>

As I mentioned, clock frequency is a design decision that is based on a lot of factors, from cache sizes, memory latency, cache hit rates, branch prediction accuracy, bus width to a host of other considerations. Current IPF designs have emphasized high IPC for various design reasons but there is no reason why the designs couldn't scale higher if this was desired. Most current high-end CPU's are running at approximately 1GHz: PA-RISC, UltraSPARC, Power4, etc. This tends to be the design target of the high-end arena.

Patrick Mahoney
IPF Microprocessor Design
Intel Corp.

 

[Duck0fD3ath]

<< x86 is one of the most complex ISA's that I can think of. With all of the backwards compatibility and strange things like self-modifying code, all of the addressing modes and other assorted quirks, I can't think of anything that comes close in terms of complexity. IA64 is an entirely new ISA that is designed to move complexity (like BTB's) off chip to the compiler. Although the two implementations of the ISA are large, high-end designs, the ISA is actually fairly straightforward. >>



Well, I shouldn't have used the word "complex". Perhaps "uncommon" would have been better. And the chip itself may not not be complex per se, but it appears the compilers will be. Other discussions on these forums have people predicting it will take several years before highly optimized IA64 compilers appear.



<< IA64 as an ISA has no knowledge of IA32. The two current microarchitectural implementations of the IA64 architecture have fully-backwards compatible built-in hardware support for 32-bit apps, and can actually boot 16-bit DOS if you so desire. These designs are not exactly speed demons compared with consumer oriented IA32 CPU's, but that's a design choice, not a limitation of the ISA. >>



Thanx for the clarification, I've seen conflicting opinions on this elsewhere. Hardware support vs. software emulation. I'll take your word for it, considering your sig.



<< That's an interesting supposition and I'm curious on what you base it on. >>



Speculation on various IT sites as to why Intel debuted IA64 at 800Mhz instead of something more. Why indeed?



<< As I mentioned, clock frequency is a design decision that is based on a lot of factors, from cache sizes, memory latency, cache hit rates, branch prediction accuracy, bus width to a host of other considerations. Current IPF designs have emphasized high IPC for various design reasons but there is no reason why the designs couldn't scale higher if this was desired. Most current high-end CPU's are running at approximately 1GHz: PA-RISC, UltraSPARC, Power4, etc. This tends to be the design target of the high-end arena. >>



Interesting. I've grown so accustomed to Intel always pushing MHz that the thought of them not doing so is alien. But I see how it wouldn't matter so much in the market IA64 is entering. I've also recently seen floating point comparisons of IA64 to Ultra-Sparc 3 in which IA64 blows away US3. So with that kind of performance, MHz may be less relevant.

Is Intel concerned about x86-64, and the possibilty it could gain market acceptance due to the relative ease and economy it grants the transition from 32 to 64 bit computing? What IA64 advantages outweigh that?

 

[Nothinman]

Is Intel concerned about x86-64, and the possibilty it could gain market acceptance due to the relative ease and economy it grants the transition from 32 to 64 bit computing? What IA64 advantages outweigh that?

IA-64 is aimed at the high-end server market, something AMD has no penetration in what so ever. AMD doesn't even have any low end server penetration and is still just starting to get real name recognition with the AOLers of the world. People think PC they think Windows on Intel. And as we've seen numerous times already, no matter how bad the product is or how much better it's competition is, if it has the right marketing it'll be accepted as the 'standard'.

AMD's Hammer have a lot of work to do to get real customers, I know a lot of Linux people will buy one just to have it if they're not too expensive (I know I'll consider it), but what really does anyone need a 64-bit processor for? The only things MS will be releasing for IA-64 right away is SQL, Exchange and something else I can't think of, maybe IIS but I doubt that's it, and they have good reasoning because no normal person really needs a 64-bit CPU for day to day use.

 

[Duck0fD3ath]

<< IA-64 is aimed at the high-end server market, something AMD has no penetration in what so ever. AMD doesn't even have any low end server penetration and is still just starting to get real name recognition with the AOLers of the world. People think PC they think Windows on Intel. And as we've seen numerous times already, no matter how bad the product is or how much better it's competition is, if it has the right marketing it'll be accepted as the 'standard'. >>



Marketing gimmicks don't work in the server market, high or low end. Such customers are better educated and informed and capable of seeing through the marketing hype, considering they are generally the in-house network and software engineers of the large corporations doing the purchasing. Further, these people generally take the time to test new kit and verify that it does what they need it to as a whole system (CPU, chipsets, mobo's, etc.). AMD has no share in the server market b/c they have not yet been able to supply such compelling complete solutions, especially when it comes to multiprocessor systems.



<< AMD's Hammer have a lot of work to do to get real customers, I know a lot of Linux people will buy one just to have it if they're not too expensive (I know I'll consider it), but what really does anyone need a 64-bit processor for? >>



That's my point, "real customers", meaning the server market, not the PC enthusiast market or the AOLers. It appears to me the main advantage x86-64 has over IA64 is that it simplifies the transition from 32bit to 64bit. But will it really do this in practice? Most corporations buy 32bit Wintel machines for desktop use, and 64bit Unix boxes for the heavy stuff. Will they really start buying x86-64 boxes with 32bit Windows on them and 1GB RAM, then later upgrade to 64bit Windows and >4GB of RAM so they can use the same box as a database server or exchange server? I don't see that, rather I see that desktop box sitting on the desktop indefinitely, regardless what processor it has in it. When companies make purchasing decisions for their database and email servers, this will be for 64bit boxes period, not for 32bit ones later upgradeable to 64bit. Hammer will compete with IA64 (and SPARC and PA-RISC) primarily on its 64bit merits. So my question stands, why buy x86-64 over IA64 for your server systems when you never have any intention of using it for 32bit apps?

 

[HouRman]

haha, I remember having this debate over a year ago with the x86-64 vs IA64 type threads. If I remember correctly, I thought lots of people would have Itaniums in their houses in a year or two. Guess I was wrong about the Pentium4.

 

[Nothinman]

Marketing gimmicks don't work in the server market, high or low end. Such customers are better educated and informed and capable of seeing through the marketing hype

You'd be surprised...

AMD has no share in the server market b/c they have not yet been able to supply such compelling complete solutions, especially when it comes to multiprocessor systems.

You don't think it could be the fact that no big names like Compaq or Dell offer AMD solutions?

It appears to me the main advantage x86-64 has over IA64 is that it simplifies the transition from 32bit to 64bit.

It does, but why the transition? 90% of the computers in the world don't need 64-bit computing, the ones that do already have them running unix. All I see them selling is a few development boxes, so developers can write code for 64-bit boxes and be able to write, compile and run it all locally. But maybe they'll have some server offerings from Compaq or Dell that will help them out in that respect.

Hammer will compete with IA64 (and SPARC and PA-RISC) primarily on its 64bit merits. So my question stands, why buy x86-64 over IA64 for your server systems when you never have any intention of using it for 32bit apps?

Because IA-64 is so dependent on compilers for good code that Hammer will probably start off with a decent performance lead.

 

[Duck0fD3ath]

<< You don't think it could be the fact that no big names like Compaq or Dell offer AMD solutions? >>



And why don't they offer AMD solutions? Michael Dell said publicly last year that the reason is b/c AMD's server solutions just aren't up to scratch. Of course, Dell is Intel's biatch, so I'll believe they seriously consider AMD when I actually see a Dell with AMD inside. Until Compaq recently standardized on IA64 they were relatively unfettered and might have offered AMD solutions, but didn't. Why not? I think for the reasons I mentioned - AMD's server kit wasn't competive with Intel's, or at least as trusted by corporate America.



<< It does, but why the transition? 90% of the computers in the world don't need 64-bit computing, the ones that do already have them running unix. >>



That's my whole point. Why the transition? And is a typical 32bit box easily transformed into a 64bit one, even with Hammer inside? Or will companies simply buy 32bit boxes for 32bit jobs and 64bit boxes for 64bit jobs, and never the twain shall meet? If that happens to be the case, then I don't see what's so compelling about x86-64.

 

[Nothinman]

I think for the reasons I mentioned - AMD's server kit wasn't competive with Intel's, or at least as trusted by corporate America.

And trusted by corporate America means brand names. I know managers who would order the Intel based stuff just because they don't trust the AMD stuff (because of the old AMD problems with K5s and sh!t). Even if AMD's techinically in line or better than Intel's stuff, they're going to have a helluva time getting their foot in a lot of doors.

Or will companies simply buy 32bit boxes for 32bit jobs and 64bit boxes for 64bit jobs, and never the twain shall meet?

That would be my guess, except in the few rare development cases.

If that happens to be the case, then I don't see what's so compelling about x86-64.

Well I'm betting the performance will start out better than IA64 so that might help, but anyone who buys a Hammer based box to 'maybe later use as a database server' or something like that, shouldn't be making those decisions.

I think they might just be going for name recognition with x86, it's something a lot of people know and trust and since this is just a 64-bit version of it, it'll be easier to move to, or whatever.

 

[imgod2u]

It's all about marketing hype. While 64-bit extensions won't bring about any noticable difference as far as the average user, look at how many people are spurting out "wait for Hammer" and I doubt they're all in it just for the added integrated memory controller. People see "64-bit" and they think "wow!". And I'm guessing that's what AMD will use as a major PR slogan "we're 64-bit!". Hey, if it'll reap in the profits........

 

[Duck0fD3ath]

I think I agree with Nothinman, the only advantage AMD will have (initially) is better performance, perhaps, while Intel optimizes IA64 compilers. After that, who knows which will come out on top. Athlon is a good design, Hammer is just a 64bit Athlon, able to address practically infinite memory which opens the server market to AMD more than 32bit Athlon ever could. The integrated memory controller is pretty cool too. Also, if Itanium 2's die size is as large as Merced, then Hammer should be a lot cheaper as well. So price, and intially at least performance are the answers.

 

[imgod2u]

I don't think comparing IA64 to Hammer is a correct comparison at all. They are aimed at completely different markets and run entirely different software. If you run software that's normally written for the x86 market, yes it won't run well on IA64. If you run high-end server software made to run on RISC CPU's such as Spark and Power, it won't run well on Hammer.

 

[Locutus4657]

Besides marketing propaganda what makes you say this?



<< I don't think comparing IA64 to Hammer is a correct comparison at all. They are aimed at completely different markets and run entirely different software. If you run software that's normally written for the x86 market, yes it won't run well on IA64. If you run high-end server software made to run on RISC CPU's such as Spark and Power, it won't run well on Hammer. >>

 

[dexvx]

Besides marketing propaganda what makes you say this?

<< I don't think comparing IA64 to Hammer is a correct comparison at all. They are aimed at completely different markets and run entirely different software. If you run software that's normally written for the x86 market, yes it won't run well on IA64. If you run high-end server software made to run on RISC CPU's such as Spark and Power, it won't run well on Hammer. >>


Highly optimized Sun software won't run well on anything else than a Sun system. Highly optimized HP software wont run well on anything but an HP system. From what i've seen modularity and portability are a joke for very high end systems. High end server markets have software that are designed specifically for that system. IA64 is designed for scalability for up to hundreds of CPUs and Hammer officially only goes up to 8. Their markets will overlap at the "low end" but certainly not anything above that.

And do you seriously think that the initial Hammer will be cheap? Its in my opinion that they will go for prices in the few thousand for CPU alone, because AMD repeated stated that they were solely targetted for servers.

Another reason why AMD hasnt had market penetration in the workstation/server market is because they dont have the validation of the likes of the others. The only AMD board that has the decent validation is the 760MPX. Go ask any major company whether they perfer an Intel or AMD system, most of them wont even poke an AMD system with a stick mainly because of validation and questionable stability (especially with VIA chipsets). Most poeple acknowledge that AMD is a better price/performance ratio, but most wouldnt care to lose even one bit of stability for a decent gain in performance (hence i845's domination in the oem market despite SIS solutions beating it performance and price wise). End users like most of us wouldn't care less because I for one dont care if my computer randomly crashes like twice a year.

 

[imgod2u]

<< Besides marketing propaganda what makes you say this?



<< I don't think comparing IA64 to Hammer is a correct comparison at all. They are aimed at completely different markets and run entirely different software. If you run software that's normally written for the x86 market, yes it won't run well on IA64. If you run high-end server software made to run on RISC CPU's such as Spark and Power, it won't run well on Hammer. >>

>>



The difference between Sun's Spark and IA64 isn't as drastic as x86-64 and Spark. x86-64 will be aimed at the workstation market, which runs entirely different software than the high-end server market. Currently, that workstation market uses Xeons (mainly) and hence, x86 makes sense. x86-64 may even make sense. But the high-end server market has said goodbye to x86 long ago. I highly doubt they'd want to go back.

 

[PowerMacG5]

Currently IA-64 can only run 64-bit application. The Itanium will not run 32-bit applications. On the other hand, x86-64 is basically a 32 bit CPU with 64 bit instructions added onto it. An x86-64 bit processor will run 32 bit applications, as well as 64 bit. IA-64 is entirely different from x86.

 

[pm]

<< Currently IA-64 can only run 64-bit application. The Itanium will not run 32-bit applications. >>

As I stated earlier in this thread, this is incorrect. Both the Itanium and the upcoming Itanium2 processors have full on-chip hardware support for all x86 applications. You can load Windows 95 on an Itanium and it would work.