geeze, nfaq, could you spout out any more lies and half-truths? I don't much give a darn either way about 'who is better' for the 64-bit market yet, but at least I know more than <i>that</i>.
The IA64 series has always been a 64bit chip 100% ... Only recently, with the release of the 64bit AMD CPUs, has Intel dropped their stance on 64bit "ONLY" and are looking to add "32bit emulation" into the Itanium CPU.
The IA64 chips have <i>always</i> had 32-bit emulation. When the first Itaniums were launched it was a big joke to many people just how bad they ran 32-bit code, but they <i>did</i> run it. Intel however has reassessed how poor this emulation runs and is recently <i>improving</i> the speed of the emulation. Intel isn't only now adding the emulation. It's <i>always</i> been there.
its been in limited "development" for the past 3-4 years and is not a mass-production product yet. The AMD Opteron is a mass production product.
Have you heard of supply and demand? Anyone who wanted one had one available. Intel has so many FABs that it doesn't have to constantly be spewing out Itaniums that might never get sold. AMD on the other hand has no real choice considering their extremely limited FAB space.
Imagine how much of a SLAP in the face this is to all the computer companies who have blown millions on helping to "develop" the Itanium all these years.
I'm sorry, but this statement didn't even make sense in the slightest. <i>No one</i> buys a 64-bit processor from IBM, Sun, Alpha, etc. to run 32-bit code. Why should Intel have done this any differently? On top of that there really <i>are</i> advantages to coding for the IA64 that don't exist in IA32/x86 or even x86-64. So how is it possibly a slap in the face of anyone that Intel is improving the performance of their 32-bit emulation?
The Itanium 32bit emulation is an EMULATION os x86 code, which will result in a performance hit.
What's your point? No one buys an Itanium for the purpose of running 32-bit code at high speeds in the first place. Hell, until AMD (and possibly Apple's G5) no one buys any 64-bit server or workstation to run 32-bit code at high speeds. Why should Intel's 64-bit chips be treated any differently in your mind than anyone else's 64-bit chips that had already been in the market before Itanium had been?
Anyone care to remember the infamous 820chipset with the LAST-MINUTE addition of the MTH (Memory Translator Hub) in which these "State of the art" Intel board were MUCH SLOWER than the older BX boards which were on the market for more than a year... close to 2 years!
Wow. Could you get any more wrong? The i820 was designed for RDRAM. It wasn't meant to run SDRAM <i>at all</i>. Pairing an i820 with PC800 RDRAM ran absolutely fantastic.
Then customers complained because Intel didn't have any new SDRAM solutions. So <i>after</i> the i820 was released Intel invented the MTH to convert SDRAM signals to RDRAM signals and back. <i>This</i> was slower, yes. It could only valguely be called emulation though. It was more along the lines of a simple hardware CODEC. And it certainly wasn't last-minute anything.
Oh yeah, the 820 was crap, bombed and cost Intel and many PC manufactures millions in recalled motherboards.
Oh. I see that you <i>can</i> get it more wrong. The i820 was a great RDRAM chipset for the P3. It wasn't the i820 chipset that was recalled. It was the MTH that was recalled, which <i>only</i> affected the i820/SDRAM combination. (Which most people were avoiding because of the bad performance involved with the MTH's translations and because the BX could in fact OC to a 133MHz FSB pretty well.)
On top of that, the MTH 'flaw' is a misconception that was generated by AMD fanatics. The MTH worked perfectly fine. It was the simple fact that a <i>limited few</i> of the 3rd party motherboard manufacturers were <i>not</i> following the specifications for the MTH. This resulted in a very small percentage of boards with these 3rd party non-specced MTH implementations to have stability problems, which was an incredibly tiny fraction of the total number of MTH boards produced.
Since there was no way to actually determine which mobos were unstable though, and since Intel hates people equating instability to Intel, even if it's through a 3rd party motherboard manufacturer, Intel recalled all MTH-equipped mobos. <i>Which</i> Intel covered the costs of the recall, <i>in full</i>. No PC manufacturer nor 3rd party manufacturers lost <i>any</i> money at all from the recall.
And considering that the recall was because some 3rd party mobo manufacturers couldn't have been bothered to follow the MTH's specifications, it was a darn nice thing for Intel to do for its customers to do the recall at all instead of just publicly blaming the 3rd party manufacturers, who by the way deserved the blame in the first place. (Okay, admittedly Intel didn't do it to be nice to customers. They did it to protect their image. Still, it worked out well for customers.)
And further, in the end the few customers who had actually purchased motherboards with an MTH generally ended up recieving upgrades to the i820 with RDRAM anyway (and if they didn't it was only by their choice since that was one of Intel's options), getting <i>better</i> performance without costing them a dime. So the recall actually worked out to the customer's benefit in the end.
The whole MTH debacle is the perfect example of a company going out of it's way and bending over backwards to fix someone else's problems and then having the spin-doctors making them out to be the bad guy in the end.
So not only does this have absolutely <b>nothing</b> to do with Itanium, but you're also compeltely and totally wrong in every single relation and implication that you were trying to make.
The AMD Opterons and AMD Athlon64 CPUs run native 64bit mode and native 32bit mode.
They however don't run native 16-bit, 32-bit, and 64-bit code at the same time, so I'd hardly call AMD's implementation perfect.
When running Windows64bit, you CAN AND WILL RUN 32bit Windows software at FULL SPEED... along side your 64bit OS and other 64bit apps.
<i>At full speed...</i> Just what exactly <i>is</i> full speed, hmm? The 32-bit apps won't gain any of the performance benefits from the extra registers. Therefore their performance <i>will</i> suffer compared to 64-bit apps being run on the exact same processor. Can you <i>really</i> call that 'at full speed'? It's a highly subjective term having more than one point of view.
Itanium? Don't know... Intel has to add a function to a chip that was never meet to be there. This adds more costs, more space...
Again, the cost and space for this emulation is already a part of the chip and has always been so from the very beginning. On top of this it is actually pretty small.
remember, the CPU is spending its cycles Emulating a x86 32bit CPU - so IF it is to do 64bit computing at the same time... you have lost quite a bit more performance again.
Again you tell half-truths. The 'emulation' is on a low level, translating the 32-bit operations into the IA64's language. So in the end the operations are then run through the processor the same both 32-bit and 64-bit. This takes hardly any more time to do than running native IA64 operations themselves.
Does it run 32bit code slowly? Well sure. Why? To be fair, look at the MHz of the CPU itself. If you had a Pentium4 at that slow of a MHz you'd have pretty slow code too. Are you expecting this to somehow magically compare to a 3GHz P4?
The emulation doesn't slow down 64-bit operation any more than any additional 64-bit code would. The bad 32-bit performance is mostly related to the clock of the CPU itself. It doesn't add any significant cost. It doesn't make the CPU significantly larger. And it doesn't impair the processor's performance with 64-bit applications. It's only fault is that it's slow for running 32-bit apps, which no one in their right mind would buy an Itanium to run anyway.
The first to market with mass-market 64bit for both business servers, workstation and very soon - consumers... AMD. At 1/4 the price!
Perhaps you've heard of Sun?
The Pentium5 is a faster version of the Pentium4... both 32bit CPUs.
Yeah. So what's your point with this statement?
PS: Re-compiling 32bit software to 64bit version is not difficult for the AMD64 bit CPUs. (64bit intel chips are NOT x86 compatible) Some reports have said that even for a game like UT2003 - 2 days of recompiling had yeilded a 50% performance increase! In a word... WOW!
Of course it's not difficult. It's even easier than porting code from 16-bit x86 Assembler to 32-bit x86 Assembler. The real question is, just exactly how many software companies will bother? And just exactly how well will the A64 actually run 32-bit code? And will the A64's inability to run native 16-bit, 32-bit, and 64-bit simultaneously pose any problems?
No# of 64bit intel systems I've personally seen = 0
No# of 64bit AMD systems & mobos I've see = 12
This completely explains why you know absolutely nothing about Intel and/or are purposefully spreading FUD about Intel. It's no wonder that you have no objectivity in the issue. So do you honestly expect <i>anyone</i> to take you seriously then?
Amiga - The Original Power
It's funny that your autosig is the first unquestionable statement that you've made.
"<i>Yeah, if you treat them like equals, it'll only encourage them to think they <b>ARE</b> your equals.</i>" - Thief from <A HREF="http://www.nuklearpower.com/daily.php?date=030603" target="_new">8-Bit Theater</A>
Facebook
Twitter
Instagram