[citation][nom]sykozis[/nom]Criminal acts aren't protected by non-disclosure agreements or no-compete agreements. If HP is in fact paying Intel to keep Itanium alive in an effort to force Oracle to continue developing for Itanium based systems, neither a non-disclosure agreement nor a no-compete agreement would legally prevent Mark Hurd from talking. Now, if HP is paying Intel strictly for their own gains....it's a different story and HP will eventually have to prove it and could possibly take legal action against Mark Hurd as a result.x86-64 has nothing to do with Intel killing off Itanium. Clock for Clock, Itanium outperforms the Opteron processors. What actually hurt the Itanium processor was it's initial inability to execute 32bit code, which was corrected with the Itanium2. Most companies that were likely to buy into the Itanium processors, chose to go the route of the Xeon and Opteron due to native 32bit support.[/citation]
Wow, you packed a lot of disinformation in one post. Nice job.
In fact, you're completely wrong. The original Itanium had 386 support built into the hardware of the processor. It was removed, and instead they offered support only via software emulation in later versions.
Clock per clock is really a useless measurement unless they run at the same clock speeds. The Itanium and Itanium 2 were designed to run at much lower clock speeds, so of course they should do more per clock. They ran their L1 cache with 1 clock cycle access, for example. You can't do that and get decent clock speeds. The only real measurement is IPC x clock speed.
Even performance isn't the most important thing. The Itanium long ago eschewed absolute performance for greater reliability and features relating to that.
It's sad to see x86 win, because it's a garbage instruction set that should have been eliminated years ago. When you consider all the extra silicon, and extra energy used to power this miserable instruction set, times the number of people that use it, and the time they've been using it, the costs are quite high. But, it looks like it might kill yet another instruction set. It's a pretty strong argument for the fact no one really knows anything; no one would have predicted in 1978 that a lousy processor, with an obnoxious instruction set that was hastily thrown together, could possibly have any relevance today. That it is the most significant instruction set in the history of computing over 30 years later, is nothing short of unbelievable. It's also pathetic, and wasteful.
Wow, you packed a lot of disinformation in one post. Nice job.
In fact, you're completely wrong. The original Itanium had 386 support built into the hardware of the processor. It was removed, and instead they offered support only via software emulation in later versions.
Clock per clock is really a useless measurement unless they run at the same clock speeds. The Itanium and Itanium 2 were designed to run at much lower clock speeds, so of course they should do more per clock. They ran their L1 cache with 1 clock cycle access, for example. You can't do that and get decent clock speeds. The only real measurement is IPC x clock speed.
Even performance isn't the most important thing. The Itanium long ago eschewed absolute performance for greater reliability and features relating to that.
It's sad to see x86 win, because it's a garbage instruction set that should have been eliminated years ago. When you consider all the extra silicon, and extra energy used to power this miserable instruction set, times the number of people that use it, and the time they've been using it, the costs are quite high. But, it looks like it might kill yet another instruction set. It's a pretty strong argument for the fact no one really knows anything; no one would have predicted in 1978 that a lousy processor, with an obnoxious instruction set that was hastily thrown together, could possibly have any relevance today. That it is the most significant instruction set in the history of computing over 30 years later, is nothing short of unbelievable. It's also pathetic, and wasteful.