Slashdot Mirror
A Brief History of Chip Hype and Flops
On CNet.com, Brooke Crowthers has a review of some flops in the chip-making world — from IBM, Intel, and AMD — and the hype that surrounded them, which is arguably as interesting as the chips' failures. "First, I have to revisit Intel's Itanium. Simply because it's still around and still missing production target dates. The hype: 'This design philosophy will one day replace RISC and CISC. It is a gateway into the 64-bit future.' ... The reality: Yes, Itanium is still warm, still breathing in the rarefied very-high-end server market — where it does have a limited role. But... it certainly hasn't remade the computer industry."
I don't know enough about the architectures to say which one is better (x86-64 vs IA-64) but backwards compatibility with x86 is a big win for x86-64.
I don't think so. x86-64 is fully backwards-compatible with x86. Itanium is not.
Wanna guess why they're not that popular?
You don't know the architecture? The first Itaniums had hardware x86 processors. The only reason they don't now, is that it was found to be faster to emulate the x86 than run it with a diminished hardware.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
The biggest advantage of AMD x64 over Itanium is the ability to run x86 32-bit code natively without any performance penalty.
The comparison is not just about better technology. Think of the trillions of lines of x86 32-bit code that has been written.
Would you render all this code unusable just because you want to move to a better architecture.
A short paragraph about Itanium (or, as the Register likes to call it, Itanic)? A few brief paragraphs about PowerPC? A few brief paragraphs about Puma?
Come on. There's a lot more scope for this sort of article. What about Rock, promised three years ago, with tape out two years ago, and yet we're still waiting for systems? What about the iAPX 432?
You've got the basis for a good article, but dear $DEITY, flesh it out! There's more meat on Kate Moss than on this article!
The Itanium is not superior at all.
Even before the AMD64, the Itanium was only good at mainly contrived FPU benchmarks. It was dismal in integer performance.
When you didn't care about x86 compatibility and wanted to spend lots of money for the usual reasons, it was better to go with IBM's offerings like POWER (which is still a decent contender in performance).
Intel couldn't offer you much else other than the CPU. They had to rely on HP, who just left their Tandem and VMS stuff to rot. Yes there were other big names pretending to do Itanium servers, but in practice it was HP.
The Itanic was an EPIC failure.
I worked on Itanium/Merced. Keep in mind I was mid-level (not high enough to see the good political fights first hand, only getting the after effects). Below is my opinion from what information I saw or collected at the time. Take it or leave it as you will.
Itanium (or I-Tanic) was supposed to be the P7, back when Intel still used P#s for chips. That Pentium 4 was never supposed to exist. Basically, Itanium was so bad, the Portland design teams came in a ate the Santa Clara team's lunch.
The biggest problem for I-Tanic was management, on many levels. ... finally. He lasted about 3 months, until his wife (supposedly) gave him the "me or CPU design" ultimatum. He then moved up to start the Intel DuPont site (which was supposed to be as big as the Portland cite). That didn't work out so well for him.
1) No good top guy
The main and original project lead was more focused on marketing and "the platform" than actually making the chip. So, there was no top leadership at the CPU design level. This allowed the "lieutenants" to squabble among themselves (more later).
They finally got a good guy in (who's name I hate to say I forget. It was a long time ago). I believe he had done Kalamath. The project was in a never-ending re-design spin at this point. When he was there you knew there was a Captain of the ship. You weren't 100% sure he was sailing in the right direction, but felt things were moving
His hand-picked successor lasted about 1 week before "family reasons" caused his resignation. I assume he looked at the state of the now 2 year delayed chip and ran.
2) Dot.com boom & Silicon Valley
The "lieutenants" didn't give a rat's ass about the project. It was mostly a "pump and dump". Being the Dot.com boom and in Silicon Valley, their main concerns were taking over ownership of a "cluster" (State sized chuck of the chip), getting the ownership on their resume, finding a new non-Intel job, and splitting.
So, every part of the chip got a new guy every 9-12 months who blamed everything on the previous owner, forced a re-design on the part (which may have been needed, but seemed to be needed an awful lot), and then left (forcing the cycle to repeat).
3) Constant Re-Design
Look I know re-design is part of engineering. But perpetual hamster-wheel-like re-design is not good. Nothing got finished!!!! No specification was stable (let alone the written specs; I mean verbal specs). You ask people (and this was years, years into the project) about your interface to their part of the chip and they wouldn't have coded it up yet. So, who knows what the Hell the timing issues would be. "Can I move a flip-flop to your unit?" "Go fish. I haven't coded that."
Let us also remember that back then (I doubt they still do this) you coded in iHDL (not VHDL or Verilog) using macros for AND & OR gates. So, you're basically doing stencil EE work using a programming language. You want an IF-THEN construct, well break out the K-maps because you'll need them.
4) Moral
After the chip had slipped 2+years, no one wanted to work on this thing anymore. They had to freeze internal transfers. You had to threaten to quit to get out. "I am leaving Itanium. Are you going to make me leave Intel to do it?"
You are uninformed. The AMD multi-core "problem" is a software problem.
People who programmed for single-core systems assumed that the processors internal tick count, called the timestamp counter (read with the RDTSC instruction), would be monotonically increasing. The fact is that each core could have its own timestamp counter and if a process is migrated to another core by the OS scheduler, then the monotonically increasing assumption falls flat (time can appear to run backwards.) This is true for AMD multi-core processors as well as ALL (AMD and Intel) multi-processor setups.
The AMD patch does several things, one of which is to instruct windows to not use the timestamp counter for use in its own time-keeping. Windows XP defaulted to using this timestamp counter for timing, because both dual-core and multi-cpu systems essentially didnt even exist when it was released. This is accomplished by a simple alteration to boot.ini telling windows to use PMTIMER instead of its default.
Any modern games that are not fixed by the above patch were programmed by stupid people. Thats right... Stupid. They are accessing hardware directly rather than going through a standardized time keeping layer. Their assumptions about time are wrong when using RDTSC, because it isnt a time-keeper. Its a tick counter specifically associated with a CPU (Intel/AMD) or CORE (AMD)
"His name was James Damore."
The first Itaniums were pretty much a dismal failure...
They ran at around 800mhz, so clocked lower than x86 systems of the time which were around 1.4ghz if i remember (and the mhz myth still very much alive, with intel fuelling it using the p4)... Their x86 support was roughly the speed of a p90 and therefore of little use beyond running one or two small legacy apps.
In terms of outright performance they were behind Alpha and Power at the time, so much for this new architecture. And when it came to price and power consumption they were behind everyone else.
When Itanium2 came around it performed a lot better, still guzzled power, and they realised that software emulation of x86 was faster than the hardware support, other than that the chips were still too expensive for what they were.
Now, Itanium is pretty much relegated to the high end niche that Alpha occupied before it was canned.
Itanium suffered from end users being locked in to proprietary binary only software - which only the original vendor could port... Some were unwilling, some didn't see the business case, some demanded that HP/Intel fund the porting, only they couldn't fund everything, so Itanium is left with a very limited set of apps...
OSS support was better, but it suffered from the high cost and rarity of the hardware, in that hobbyists had little chance of getting hold of the hardware to play with.
Personally i think HP/Intel would have been better off putting the effort into continued development of Alpha... It already had a software and user base, it already had x86 emulation which performed reasonably well, and it had a legacy behind it of old hardware that was cheaply available to OSS developers. Even today, Alpha versions of Linux seem far more active than the IA64 versions... Plus any customers already using Alpha would not have needed to migrate (and many of them migrated to Sun or IBM).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Why is that even in there? It "only" powers all three current games consoles and IBMs Power Systems server lines (i and p).
If that's a failure, I hope IBM has many more failures in the future.
the "Itanium" approach that was supposed to be so terrific - until it turned out that the wished-for compilers were basically impossible to write.
(http://www.informit.com/articles/article.aspx?p=1193856)
When Don Knuth says your chip is impossible to program for, you're in deep, deep trouble.