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."
If AMD hadn't rushed with their 64 bit version of the x86, about now, itanium would be getting popular and hence cheap. ...
Market forces have so much to do with technology advancement. A lot of times, superior technology has to take a back seat
Dont make a better sig, you insensitive clod!
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.
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?"
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!
Itanium did one thing well...it killed a lot of other chips. The threat of it killed MIPS post-R12K plans - and the Alpha, and PA-RISC architectures as well.
Here's an idea: Let's throw out years of proven engineering in favor of an architecture that has yet hit silicon. That way we can fire our engineers and pocket the change. What could possibly go wrong?
I feel a big bonus is coming up, and just to be safe let's add a parachute too.
HP/Intel would have done better, technically, to work on Alpha, but they couldn't sufficiently dominate the market for their tastes in that case. half the point was to have something that they controlled, and Alpha, while technically great, was already too widespread for that.
which, really, is the most important response to the original parent's point. what was AMD supposed to do, sit around while Intel dictated what the terms of the next stage of the market would be? what gives Intel some inherent right to that sort of dominance? AMD did exactly the right thing, from a business perspective: they saw what they believed to be a strategic mistake that left a market hole open, and produced a product to fill it. turns out they were right.
turns out it was the right thing to do technically, too. when Itanium hype was at its peak, i remember lots of actual engineers i knew (and even some subset of the tech press) pointing out that EPIC was really just tweaked VLIW, and that had been tried and failed a few times. amd64 has consistently outperformed IA64.
even the quote in the summary is misleading. yes, IA64 is still plodding along in the high-end server market, but it's even an also-ran there. POWER and amd64, in particular, continue to trounce it, both for your normal "server" market and for the really high end scientific cluster stuff (it's got, what, one spot on the top500 list?). it's a pretty substantial failure, really all around.
i speak for myself and those who like what i say.
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).
I have to believe that there were forces inside Intel that wanted Itanium to fail. It's hard for me to believe that if the project was this important they wouldn't have pulled some Top Guy that Gets Things Done on the project.
After the chip had slipped 2+years, no one wanted to work on this thing anymore.
Back in 2000 or 2001 I went to JavaOne and went to a talk by some Intel engineers about how cool Itanium was going to be. They had to be he least enthused about any project I'd ever seen. The paper features sounded pretty cool, but you'd talk to them and you could just tell they thought the thing was a total piece of garbage. They didn't say it outright of course, but the sounds of their voices and the expressions on their faces told a very different story.
AccountKiller
The answer is emulation and a much better architecture. Emulation can run applications at 50% of the host speed in most cases now. For tight, mathematically-intensive loops, it's more than this, for things containing a lot of branches it tends to be lower.
When I replaced my 1.5GHz PowerPC Mac with a 2.16GHz Core 2 Duo, I didn't notice the speed difference on legacy code. I forgot to replace VLC with an Intel build for a while (they do universal binaries now, but they didn't for a while), and even the PowerPC version in the emulator could play H.264, although the CPU load spiked to around 80% on both cores. Switching to the native version dropped this down to around 20%.
When people talk about backwards compatibility, what they really want is two things:
If you can only run DOS software at the speed equivalent to a 200MHz Pentium, do you think anyone will care? It was most likely written for a 16MHz 386, so you're still running it fast enough. I can play all of the old DOS games I own, the ones that used to make my machine struggle when they were new, in DOSBox on a PowerPC machine, and they're fast enough.
Backwards compatibility isn't nearly as much of a problem as persuading developers to support your architecture for new programs. Any new chip can emulate a three to six year old chip from another architecture at a reasonable speed.
I am TheRaven on Soylent News