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!
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?
How could the writer blatantly ignore the 486sx, the winchip, or the original (cacheless) Celeron??
Although, I've always contended that TI's 486dlc (which fit in a 386 socket) was one of the worst chips I ever used, it overheated, lacked full 486 compatibility, and froze up the system with random halts whenever I needed to get something done on it!
Back in 1999 the ACE Consortium had Compaq, Microsoft, MIPS Computer Systems, DEC, SCO, and a a bunch of others.
The plan was to launch a MIPS based open architecture system running Windows NT or Unix. Back then the MIPS CEO said MIPS would become "the most pervasive architecture in the world". The whole thing fell apart as Compaq defected, MIPS run out of cash and got bought by SGI. Dec obviously moved to supporting Alpha instead. Microsoft shipped NT for MIPS, Alpha and PPC for another few released and then gave up the ghost.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
AC how could you have forgotten to mention the socket 4 Pentiums, or the K5 on AMD's side, the Transmetta Caruso, the Cyrix MII, or the slot 1 PIII 1.13?? From the extraordinary cost alone, you could have also called most of the intel overdrives a flop too.
although the winchip (shudders) I hope no one was unlucky enough to have to depend on a box with one of those running it
The PowerPC architecture was dumped by Apple and failed to challenge Intel in the PC market in a big way.
You missed the proper order. The PowerPC architecture didn't have the money behind it that the x86 architecture did. Take a crappier design but spend a ton more money on it, and you can easily make it faster than a better design.
The PowerPC failed to compete effectively against the Intel/AMD competition, and thus, Apple was pretty much forced to switch because of simple economics.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Reading through the article, it seems that other than AMD's Puma, most of these failures have one thing in common: they are not backward compatible with the chips they replace.
People are loathe to buy a new computer and all-new versions of software to run on it. Look at the 64-bit Windows architectures. How many folks are running 32-bit software on those?
Bottom line is that the software IS the computer and the chips ultimately are sexy only to EE's and gearheads.
Well, I guess having better compilers for IA64 would helped greatly, considering that the architecture's performance is critically depending upon the compiler detecting instructions that are not interdependant.
That's pretty much right on the head there. Intel made the IA64 under the assumption "make a better chip, and the compiler will follow", unfortunately, they didn't realize how much inertia was behind x86. AMD exploited it and POOF, Itanium goes down in flames. :(
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
I just got out of my bed 2 minutes ago and by vaguely reading the word FLOP I thought about Floating point Operations Per Second...
Here be signatures
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 ...
Perhaps, but how superior is that superior technology?
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
It was a neat idea, but advantages in manufacturing technology favored CPUs with more complicated front ends. The Itanium advantage never materialized on the desktop, so had this "superior" technology taken off we'd might have had faster computers at the cost of making our software run on this bling architecture.
Making big ISA changes for a mere speed boost is not worth it, and it's not certain you'd get even that as the Itanium does not always outperform the x86.
It turns out that the cost of a translation layer has become irrelevant as chips have gotten faster. It's not even considered a pipeline stage any more, not really. That is, it is no longer a bottleneck to have to have a layer of essentially combinational logic to convert a CISC instruction set into a mostly RISC / VLIW one internally. This savings grace is also why the fairly badly bloated intel instruction set no longer has any real impact on the performance they can squeeze out of the chips.
-Matt
TI's 486dlc (which fit in a 386 socket) was one of the worst chips I ever used, it overheated, lacked full 486 compatibility.
What app did you run that needed full 486 compatibility? Being able to plug a 486 into an old 386 mobo seems like a neat idea, and any software that ran on that 386 would of course run on the nerfed 486 right?
Too bad about the overheating though.
That definitely belongs in there. Sorry, Linus.
Stop the brainwash
AMD still won't openly admit this but there's a timing problem with all or at least most of their Athlon X2s where the cores' clocls get out of sync with each other. That causes major graphics problems in games that rely on it like Runescape and Halo 2. It also causes really strange side effects where basically the computer gets slower and less responsive over time until you restart it. I never knew what was wrong with my computer and assumed it was inefficient software but then I heard about this and OMFG was I mad! They even have a program on their website that fixes some mysterious, unnamed problem with X2s and graphics and as soon as I installed it, it worked and yet they still won't admit to the public how badly they screwed up! I didn't even see the story on slashdot but it's all over the web.
Also they should add to the list of major screw ups, the entire naming system used by Intel. Centrino sounds like Celeron and they brought back Pentiums but the Pentium D's and Pentium Dual Cores are different and then there was Core Duo and Core 2 Duo which are easy to overlook. Ugh, it's just stupid!
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
The idea with Itanium was to make a CPU that could perform on the level of RISC and CISC CPUs with a relatively simple front end. In essence the Itanium executes a fixed number of instructions each cycle, then leaves it to the compiler to select which instructions are to be executed in parallel and make sure they don't read and write to the same registers and such (instead of having logic in the CPU figuring this stuff out).
Actually you could see that Itanium was in deep trouble when it launched at a lower clock rate than x86. The whole idea behind EPIC "explicitly parallel instruction computing" was that you move instruction scheduling to the compiler, and that allows you to essentially out-RISC RISC, i.e. build a dumber chip that can be clocked faster. I think you're right about technology too. Back in the CISC vs RISC days an R4000 for example could be clocked faster than a 486 due to its ultra streamlined pipeline - MIPS originally meant "Microprocessor without Interlocked Pipeline Stages". Itaniums for a variety of reasons ended up clocked slower than x86. Partly I think too much stuff got added to the architecture, and partly I think x86 chips were already very close to process limit for frequency, so a simpler architecture wouldn't run any faster.
I sort of wonder if .Net might have been part of the sketchy Itanium strategy too. The big thing about .Net is that it is a VM that is designed to be JITted rather than interpreted. Part of EPIC was that chips would be binary compatible, at least for user code, but that old binaries would not necessarily run optimally. It's easy to see why - a binary compiled for an old chip with n functional units would have fewer instructions scheduled to run in parallel than one compiled for a new one with 2n units assuming the scheduling was done at compile time.
Of course with .Net the applications are compiled for a VM and then JITted. If you had a new chip, the .Net JITter could detect this and schedule optimally.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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!
Very little code is written in x86 assembly, the vast majority is written in higher level languages and then compiled or interpreted... When you have the source code, porting it to IA64 is relatively easy. Look at Linux, it runs on a variety of architectures, as do a huge number of applications. Many of the original authors of those apps would never have considered they might be running on IA64, Alpha, Arm, Mips or Sparc someday...
The problem is software being delivered as binaries. Binary software distribution is holding back progress, making it necessary to continue supporting old kludgy architectures instead of making a clean break to something new and modern.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Boohoo! AMD is being so *mean*! They're *competing* with us! It's just not *fair!
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.
I remember how SGI kept the team around that was going to work on their next-gen processor while they were negotiating with Intel. These guys had no work - they just played a lot of foosball in good old Building 40 (yeah, Google, you weren't nearly cool enough to build that campus). Then once SGI had sold it's soul they axed the project (and the team). That was a sad day...
"Where quality is like a dead stinking rat - you just can't miss it."
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.
Commenters seem very young today. Noone remembers the failures of Intel's and Motorola first attemps at addressing RISC designs? Both the Motorola 88000 and the Intel i860 were great designs that failed.
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.
And what sort of thorough article would this be in missing out Sun Microsystems' MAJC chip from the 1990s ?
Promised to accelerate JAVA instructions, the chip was a multithreading multicore design (can you say Niagara?) but Sun couldn't get it to market fast enough and advances in general purpose CPUs left it for dead.
Sadly MAJC only made it into two models of Suns own-brand graphics cards before it was dropped, though it's design principles live on in Niagara and Rock.
It didn't help that part of the advantage of IA-64 was that it let programmers write their own branch prediction. Which they didn't want to do.
We probably have as many PowerPC chips in our homes than x86 these days. How many people own two of the following game consoles but only have 1 PC in their home? GameCube, Wii, xbox360, PS3?
It's true that Apple killed PowerPC on the desktop and it will probably never come back. And ARM and Atom will fight over the mobile and netbook market.
The article doesn't mention POWER, so I think we can technically assume it only considers PowerPC a failure (which is wrong of course). Even though POWER and PowerPC are almost the same thing, they aren't the same thing. But governments and corporations are still ordering iSeries systems, and IBM is still making plenty of money off them. (although I bet they sell less than 100 of them a year).
“Common sense is not so common.” — Voltaire
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.
Intel's i960 was a nice chip for embedded development. One of its nicest features was the large number of individual interrupt vectors which is really useful when you want to hang off a large number of I/O devices off it. Compare that to the x86 where they have to share interrupt vectors. For some reason however Intel decided to drop the whole line and move to ARM architecture instead.
However the second one is a what might of been. During the 80's we did a lot of development using INMOS T2 and T8 transputers. They were a joy to use and made parallel programming at software and hardware level so easy and natural. The next iteration was to be the T9000. It promised a lot, much improved execution speed, a faster and more flexible processor interconnects. It looked so good we had even sold our next project based on it. However when we started getting the first samples there was obviously something wrong. Bits of the chip did not work or would fail. At the end of the day it looked like INMOS just could not deliver. The T9000 never became a reality but anyone who used transputers how good they were and and could if it had been done right with enough finance could of fundamentally changed the computer industry.
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies
... to be precise, by intel's bankroll and investment in process.
Power PC and Alpha were outcompeted by the fundamentally inferior x86 family not because of flaws in their designs, but because intel spent more on improving their process than anyone else.
Both the Power PC and Pentium turned into furnaces, the Pentium 4 and G5 were both following the "megahertz myth" into long pipelines to let the clock speed ramp up. Neither got the clock speeds they were hoping for. Both were too hot for mobile processors. In both cases the solution was going to be shorter pipelines, slower but more clock-efficient cores, and faster busses. The Freescale e700 was torpedoed when Apple went with Intel's Core Duo... because Intel had the resources to get their respin of the PIII out quicker than Freescale could get their respin of the G4 online.
So now we're still using hacks upon hack on the truly horrible x86 architecture.
Well, it could have been worse. It could have been SPARC.
If you make a better chip, the users will follow. But if you make a chip that is marginally better than x86, slower than most of its RISC competitors, and more expensive than anything with similar performance, no one will follow. This is especially true when you release an incredibly power-hungry server chip just as the market is starting to care about performance per Watt.
I am TheRaven on Soylent News
In the PC market is right. In the CPU market, I believe PowerPC is still outselling x86. Every new console contains a PowerPC chip. Quite a few handheld devices contain PowerPC chips. A lot of modern cars contain 20-50 PowerPC chips (take a look at a BMW from the last few years - it will have at least 40 PowerPCs).
PowerPC isn't the market leader though. It still lags behind ARM by a fair way. x86 is a niche player, and that niche is gradually shrinking.
I am TheRaven on Soylent News
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
Was so far ahead of its time, we still are not ready for it. Tho finally silicon has advanced far enough to make the architecture work.
( note my nick.. you can tell i was a fan :) )
---- Booth was a patriot ----
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
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.
Your comment is stupid, but I'm going to reply to it anyway. I have no idea what CSUS and UCD are running, but Yuba was offered no choice about their upgrade path - it was either completely change student records applications or buy the 8-way iTanic. Which yes, is going mostly underutilized given that the 4-way Alpha was overkill. And given that I personally set up the HP-UX to Windows ipsec integration for the system (the HP docs on IPSEC are backwards BTW, their examples are exactly backwards and do not work) and in fact I did the prior, ssh-tunnel based encryption that they were using on the Alpha server, I am entirely sure of what they are running.
I have no idea what other JCs are running, but Yuba is running Colleague under HP-UX 11i on an 8-way iTanic. And thanks to me, student information is actually encrypted between the server and the client :P (Actually, thanks to the district's money going into my pocket... it's not like I would have done it for free. HP-UX is the great satan of the Unix world. I'd walk a mile for AIX after fucking around with HP-SUX for days.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The problem is software being delivered as binaries.
I think that's chicken-and-egg: if you have a single, dominant, binary-compatible architecture then the most efficient way to distribute commercial software is as pre-compiled binaries.
Linux runs on so many architectures for the simple reason that many Linux developers take a pride in their work and actually care about interoperability: all that cross-platform support doesn't happen magically because its written in C! A substantial app will be riddled with "#ifdef IA32/#ifdef MIPS"-type, and if you compile from a tarball someone, somewhere has spent a lot of time preparing that .configure script.
Given the existence of a ubiquitous single platform with 90% of the market, there's no short-term commercial case for that sort of attention to detail (...maybe posterity will show that there's a long-term case, but since when did that amount to a hill of beans?)
Interestingly, though, most Linux distros have gone for binary packages as their main form of distribution...
My bet is, long term, "bare metal binary" software will naturally disappear in favour of scripting languages, JIT compilation and/or virtual machine bytecode. Compatibility will be determined by the API, not the hardware and, by definition, any software that still needs "raw hardware" performance will need to be hand-tailored for the hardware anyway.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
IA-64, iirc was slower than x86 when compiled with primitive compilers (read gcc).
A lot of the advancements were in floating point, which is still meaningless to most people except gamers (which wouldn't be using the platform) and special interest companies. Namely, branch-prediction's were more accurate for instructions which take 32 to 64 clock-ticks (64bit sqrt, divide, etc).
The advancements of the VLIW were negated by very-large prefetched instructions with cached pre-compiled op-codes.
The branch predictions only gave you a theoretical advantage over the very large branch-prediction buffers, and in some circumstances the branch-predictors gave you better decisions (hot code could pre-guess a direction before a predicate register was even populated - the Itanium would have to execute both paths, but the branch-predictor choose the hottest path). Further Alpha laughed at Itanium, saying they've had branch-prediction hint op-code variants for years(without predicates), and they showed many synthetic algorithms which would produce better alpha code than Itanium.. Basically saying for most algorithms, predicate-registers produce less efficient code than other alternatives (just happens that x86 didn't have any such instructions - but that would have been easy to correct with yet another op-code prefix). Note i686 did introduce the conditional move instruction, which goes a long way to small but common branch avoidance.
Register windows (a la sparc's) are a neat idea, but with register renaming on the x86, a tight function-call loop can be just as fast. Plus the spilling of registers into memory often is mitigated with the high speed cache. Further, many arguments against the small register set of the x86-32 are avoided in the x86-64's much larger register pool. Lastly, if you only have 16 registers (of which only 8 are hot), then you can efficiently utilize a pool of 256 rename-registers. If, however, you have an explicit 128 register addressibility (most of which is statistically cold), it's difficult and inefficient to remap them in future versions of the architecture. Note that every power of two register-size causes slow-downs in register interconnects - to say nothing of the real-estate and power-drain.
Then there's the fact that a program that only needs 2Gig of RAM will generally work better in 32bit than 64 due to the half-sized mem-pointers. More fits into your cache. Note other unrelated optimizations in x86-64 may counter-balance this (though this is independent of the 64bit design), so YMMV. I know that SUN's JDK 32bit runs faster, more smoothly than the 64bit version for most of our apps. Yes there are some CPU instruction optimizations for x86-64, but memory in java tends to be the limiting factor.. The same server app will consume 400Meg on a 32bit version and sometimes breaks a gig on the 64bit version. The GC times are measurably slower.
The explicit register rotation used in tight-loops - allowing a 6 op-code loop to execute every op in every stage of the loop, thus degrading a loop to at most n clock cycles is nice in theory. But what if your loop is more complex than a trivial inc/dec. And what if you need one more op-code than the architecture supports? Moreover, there's no technical reason why a CPU can't detect such a loop after k iterations and allocate register-renaming to do the exact same thing. With a hot-spot detector (part of branch-prediction), a subsequent access could fire up the loop immediately. But more importantly, future versions of the CPU could support even larger loop-lengths, as you're not explicitly limited by the bit-lengths, or the originally staticly compiled code.
The sad part is that the explicit compilation of CPU hints, and minimization of register spilling that are the hall-marks of the Itanium should theoretically lead to a slimmer, lower-power, higher-theoretical-clock CPU.. But due to other engineering decisions, the exact opposite is true. Lower clock, bigger silicon, higher power.
Basically th
-Michael
I find it interesting that the article failed to mention that variants of the PowerPC are not only in PS3s, but also in the Wii and the XBox 360. Yes, the PowerPC failed in the desktop arena, but it's been very successful in others. The PowerPC also has plenty of success in embedded markets. Does the auto industry still use 603-based chips in car computers?
Outside perception - it started even before you say but really rooted in your reason #1.
From what I could see IA64 wasn't really started for reasons of pushing technical performance, the problem being solved was the existence of clone designs. All of the IA64 IP was held by a third company, and then licensed back to Intel and HP. That way, none of the IP would be covered by existing Intel or HP cross-licensing agreements. Then the architecture had to be sufficiently different that it would be fully covered by that IP, and none of the essentials covered by anything else.
So the initial design point was driven by legal and marketing concerns, and technical considerations were a distant third place, if that high.
That's the impression from one well versed in chip design who watched from outside.
The living have better things to do than to continue hating the dead.
To complete the history, this is the Itanium II story.
Itanium (Merced) was 80%/20% Intel/HP driven. Itanium II (McKinley) was the opposite, 80% HP driven. The HP guys considered Merced garbage and did not leverage much from Merced. But it was probably already too late for Itanium II. Just like in the early days of Microsoft and Apple, the market had already spoken and placed a huge premium on backward compatibility. Both Merced and McKinley performed about 6 years behind on the performance curves when running x86 code. Intel's bet was AMD was not going to be taken seriously with 64bit-Athlon simply because AMD was too small to create a trend by itself and customers would be forced to go to Itanium. Of course Intel was wrong, but it did not hurt Intel too much. Intel always had a backup plan-- codenamed Yamhill. Intel was only a few months behind AMD if x86-64 was to take off. McKinley also suffered from political turmoil at HP:
1) HP placed a high value on seniority and balked at hiring 1-3 year job hoppers. Even industry recognized people with PhD's and 20+ years of experience at other companies were usually told they would have to start as MTS but in a year or two would get promoted to TC's. And the few people who took this bait usually ended up getting screwed. At their yearly review they would be told maybe next year; they simply have not been around long enough. This meant they had a hard time attracting top of the line talent since while HP would match salary it would balk at matching titles and power.
2) The Carly Fiorina factor was a huge blow to HP employees expectations. She did not realise how many engineers were simply at HP for the work/life balance and promise of no layoffs in recessions. HP paid about 15% less for engineering talent because of the HP Way. When Fiorina basically destroyed the HP Way a lot of 10+ year HP'ers started to suddenly look around the industry to realise they could get paid a lot more by simply jumping ship so they did. She also made it very clear she wanted to exit the semiconductor industry and the Fort Collins,CO Itanium II team saw the brunt of her complete indifference about what they were working on; no raises, inadequate funding, etc. They were basically being setup to be sold to Intel which did eventually occur.
3) The Intel buyout was also a sore point. The HP employees were given no way out. Either take it or unemployment. It was pretty obvious at this point Itanium was a failure.
4) AMD moved into Fort Collins,CO about a year later and stole the best of the Itanium II team. Even the Captain of Itanium II jumped ship!
5) What remains now is just a shell of the former team. They can't hire since Intel isn't exactly enthusiastic about Itanium's future and what good engineer wants Itanium on their resume at this point.
There is a bit of confusion in some posts here. Motorola made very good PPC chips.
Very good for embedded purposes. PPC601, the only POWER-compatible PPC chip, was outdated when it hit the market. 603 was maybe the fastest, certainly competitive - for all of about a month and intel jumped up again. The G5, same (plus the most expensive macs EVAR.)
As a desktop chip, PowerPC is a failure on all levels. The first ones weren't very fast and cost way too much. The later ones were cheaper, but were even slower compared to the competition. The latest ones were fast again, but too expensive again.
PPC followed it's own course and never had to wait for Power first.
You are just. plain. wrong. about this. The G5 was derived from POWER4. Wikipedia is not perfect, they refer to PowerPC processors as POWER architecture processors, in spite of the fact that they do not implement full POWER instruction sets. Since the ISA is the interface, this is a misnomer. But in all other regards they have the story right - all PowerPC processors are stripped versions of a POWER processor.
PowerPC is an epic failure on the desktop and is proceeding to fail in the embedded market (it is losing market share even as I type this.) Its primary purpose has been to funnel money to IBM via Apple. Its primary effect on Apple computer was to hold them back by years. It's x86 that has given Apple a new lease on life. Trying to stick with PowerPC when it became clear that x86 was going to beat the living shit out of it was one of Apple's biggest mistakes, but you can add it to a long list of other big ones.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The Sun X4600 AMD64 servers at work each have a PowerPC in the LOM processor. Running Linux, no less :-D
http://rocknerd.co.uk
I am surprised that they knocked the AMD Puma in the article while leaving the following piles of crap unmentioned:
1. The original Covington Celerons with no L2 cache
2. Original Pentiums with the FDIV bug
3. The Pentium III Coppermine 1.13 GHz that was infamously unstable
4. Socket 423 Pentium 4
5. The Pentium 4 Prescott 3.6 and 3.8 that overheated and throttled at stock speeds on the stock heatsink
All of those chips were bigger duds or had bigger errors than even the TLB error in the BA/B2 Barcelona Opterons they mentioned in the "Part 1" article.
Just "gittin-r-done," day after day.
http://www.littlelinuxlaptop.com/ - these things are widely available in the UK. They're basically toys as yet (locked down, user-hacked firmware is a hideously rough alpha), but very interesting for their potential.
http://rocknerd.co.uk
That was pretty hilarious, considering that when other chipmakers were making chips (68k, PPC, Alpha, etc) which didn't take over the personal computer market, Intel made the 80286 which could work as a fast 80806. Then the 80386 which could work as a fast 80286. Intel proved backwards-compatibility was the most important feature in personal computer processors, overriding any other concern.
They forgot, and then AMD expanded x86 exactly the way Intel had previously done twice: by making something that could work as a fast 80386.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
OK. Seems my assumption that the CFP2006 benchmarks are single threaded was wrong (it can be multithreaded and use multiple cores if "auto parallel"=yes).
Even so, the POWER6 still doesn't seem that much faster - certainly not 100% faster.
Back in 2007, the 2400MHz Intel Xeon 3060 still got a score of about 15 with only 1 core enabled. The 4.7GHz POWER6 score of 18.7 is not 50% or 100% more/faster than 15.
See:
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070329-00693.html
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070611-01218.html
You have to understand it's a bit hard to do apples to apples comparisons because:
1) Though IBM did post a 5GHz POWER6 score of 20.1 last year (2008), I don't see "cores=1" submissions for Intel chips last year.
2) There are no cores > 1 scores for POWER6.
As it is, I'm inclined to think that the x86 has caught up with the POWER6's CFP2006 performance, if not surpassed it already.
My reasoning is the POWER6 has not got much faster since 2007 (4.7GHz -> 5GHz, with no change in architecture).
Whereas the 3733MHz Intel Core i7-965 Extreme Edition is definitely a lot faster than the 2400MHz Intel Xeon 3060 - (which got a score of 15 with one core).
The i7 is a new architecture with maybe 10-15% faster per clock, and 3733MHz is a fair bit faster than 2400MHz (BTW the performance/watt is very competitive too).
So it's near certain that a 3.733GHz i7 would beat a 5GHz POWER6 in single core performance in both CFP2006 and CINT2006.
It's impressive how fast the x86 can go :p.
I don't think it's going to be easy for the POWER/SPARC/Itanium teams to beat the x86 in performance, or even performance/watt (for high performance computing).