Slashdot Mirror
Why Doesn't the Itanium Get the Respect It's Due?
happycorp wonders: "As in recent years the Itanium does well, easily beating x86 processors even at its low clockspeed (1.4Ghz). The supercomputer people are serious about benchmarking (no easily tricked microbenchmarks or reliance on closed-source
commercial apps), so the discrepancy between the performance and perception of this chip is serious.
With a single-CPU Itanium2 system at
around $2000 their price is already reasonable, and the price would come down
(and software would be ported) if the Itanium ever became a mass market chip. Having an affordable chip one step above a Xeon or Opteron in floating-point performance would not be such a bad thing for gaming enthusiasts (or 3D artists). So, the recent
article
on the
Top 500 supercomputers list brings up a question I've been meaning to ask:
Why do we see so many disparaging opinions of the Itanium processor (all those 'Itanic' jokes, etc.)?"
"It seems computing enthusiasts' sentiment is set against this processor, and its likely that it's going to be abandoned sooner or later. We'll be paying for x86 compatibility indefinitely (recall the Xeon has roughly
three times the number of transistors of the ppc970 for example; but we hardly get three times the performance).
These are a couple scores from the top 20, with the total gigaflops divided by the number of processors to obtain a per-processor speed:
rank processor ghz (gflops / #procs) speed #5 ppc970 2.2 (27910 / 4800) 5.81 #7 itanium2 1.4 (19940 / 4096) 4.86 #10 opteron 2.0 (15250 / 5000) 3.05 #20 xeon 3.06 (9819 / 2500) 3.92
Given this, consider what a 2 or 3 Ghz Itanium could do.
(fine print: I am not affiliated with the Itanium or the top500 list in any way)."
These are a couple scores from the top 20, with the total gigaflops divided by the number of processors to obtain a per-processor speed:
rank processor ghz (gflops / #procs) speed #5 ppc970 2.2 (27910 / 4800) 5.81 #7 itanium2 1.4 (19940 / 4096) 4.86 #10 opteron 2.0 (15250 / 5000) 3.05 #20 xeon 3.06 (9819 / 2500) 3.92
Given this, consider what a 2 or 3 Ghz Itanium could do.
(fine print: I am not affiliated with the Itanium or the top500 list in any way)."
Because Intel tried to force everyone to jump on the 64bit bandwagon at once, while windows didn't even support it yet, without backwork compatibility to existing 32bit software. It's a good design, just doesn't (didn't ?) fit well with the mass market at the time of the release.
I have certainly noticed a general move away from Intel in the past few years. I think they may have had a run of bad press and serious competition from other manufacturers lately.
They just aren't the juggernaut they used to be. There was a time when they built it and people came. I presume choice is what's keeping the sales down.
Why do we see so many disparaging opinions of the Itanium processor (all those 'Itanic' jokes, etc.)?
Because people repeat what they hear. Many people here only know what has been said on Slashdot about the Itanium. They've never used one. MrDicker64 said it was crap, so it must be!
I think the big problem is that it cannot run x86 software very quickly. Most software that people want to run in the mass market is precompiled, binary x86 software. That stuff just does not run well on the Itanic. That, combined with the fact that the mass market still doesn't really benefit from a 64-bit address space means that the Itanium was a more expensive, slower processor. It's no wonder that it didn't sell.
Early versions also had problems with heat. Where I work we have some Itanic workstations and in the winter, if we were chilly, we literally turned them on to help warm up our offices.
Hundreds and hundreds of products have been killed or permanently crippled because their first versions were terrible. Itanium is the same thing. With the public perception of the Itanium still the same as it was for the first (pathetic) iteration of it, how are you going to convince your manager to spend the money to get it? Benchmarks only go so far.
-Daniel
http://techworthy.com/PCUpgrade/SeptOct2004/64-Bit -Gaming.htm
Because for Itanium compatibility they'd have to port everything over to the Itanium proprietary instruction set. You can see how eager they've been to do that for Macs, so guess how likely they are to port it for Itanium.
$8.95/mo web hosting
Inertia, would be my answer to this question: Inertia of the technological kind keeps x86 on the desktop, even with the 64 bit extensions.
Inertia keeps Microsoft on the desktop, even though it being low hanging fruit for crackers.
Inertia can be a good thing... in this case, it's a bummer. I can safely say that my next game rig will be A64 powered, simply because of... inertia.
EveryDNS. Use it. It works.
AC's need not reply
People don't want a processor whose main purpose in life was to artificially refresh Intels control on much of the Intellectual Property associated with the processors. AMD is getting too close, so they change everything and hope to charge royalties.
Digital is, by definition, imperfect. Analog is the way to go.
Why anything doesn't get the respect that it is due. It is because people don't want to give it respect. The Unix People go Well Sun Ultra Sparc (Or any other of the 64 bit Unix platforms) has be 64 bit for many years before the Itanium. The Apple crowd went well the Power PC is now 64 bit (although this is changing, and may possibly give Itanium some respect). The windows users are afraid of Itanium because it may break a lot of compatibility in their legacy apps. The Linux users are afraid of a complete Intel Dominance and put their development efforts to AMD 64bit chips. It is a state where you see the old king dieing and this is your only opportunity to get a change in government before the kings son gets in power. Why doesn't FreeBSD get the respect it deserves, or why doesn't Python get the respect it deservers. The winner is not always the best or even close to the best, the winner is often the one that people feel good about.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
With a single-CPU Itanium2 system at around $2000 their price is already reasonable, and the price would come down (and software would be ported) if the Itanium ever became a mass market chip. Well, it's sort of like Linux. The only way it people will use it is if it's already a mass market chip, but it will never become a mass market chip if people don't use it. Sort of an infinite loop.
Software is like sex. It's better when it's free. -Linus Torvalds
The first Itanium was too late, too slow, and too costly. This led to a bias being developed against it based purely on misinformation. Don't forget to factor in the typical hypocritical resentment of Intel...
... wait for it ... poor legacy compatibility. Legacy support is certainly a valid and very important issue but why must people constantly hammer away at this when considering the Itanium at face value: A very capable high-performance processor which would be ideal for UNIX workstations, servers, and supercomputing applications.
People are always complaining about X86 for its legacy cruft yet when Intel designs a bold new architecture based on an extension of the VLIW approach, they get slammed for
The biggest drawback of Itanium is the fact that it's a proprietary architecture. But then again, so were Alpha and PA-RISC. POWER and SPARC might not technically be so but if you want workstation-class POWER CPUs, you've got no choice but IBM (I don't see anyone else jumping on the PowerPC bandwagon and producing competing compatible chips) -- with SPARC there's just Fujitsu and Sun's inferior offerings.
But looking at the architecture for what it is, people should be excited about Itanium. It's new, it's fresh, it's fast, and it's interesting. Certainly far more interesting (and challenging) than RISC with a lot of unexploited potential.
Its easier to harness the power of many horses than grow one 100 times as powerful.
No, it is easier to grow 100 horses than one horse 100 times as powerful, and yet we've gone ahead and done it anyway, because, in point of fact, it is easier to harness and control one horse than 100.
See The Wheel of Reincarnation.
KFG
Microsoft apps are nonexistent, and open-source apps tend to have crappy performance due to the fact that IA-64 depends overwhelmingly on compiler optimization. Developers can use Intel's compiler, but it requires work to use with most Linux systems (the only other platform that supports IA-64 besides MS, AFAIK).
Net result: no applications => no uptake, QED.
Egg, chicken, all that.
Lacking <sarcasm> tags,
You have floating-point listed there, which is great for science I'm sure, but where are the integer numbers?
I have seen the future, and it is inconvenient.
The itanium is an amazing architecture with so many performance boosting upgrades that it would have blown everything out of the water.
If it came out on time.
It was so late that by the time it came out it was still better than existing processors, but not by a large enough margin to justify its cost.
As the clock speed goes up, and as the other processors find their limitations and drop out of the race, the Itanium will look better and better. There is, however, a large investment in time and software that must be made before it becomes truly useful. It is unlikely that MS is going to support more than one architecture simultaneously for the desktop or server as it tried to do for x86/alpha.
The big marketing push and the number of companies signing on to the good ship itanic coupled with the constant pushback of the release date caused Intel to lost a lot of the press attention they should have received when it did come out.
It'll be interesting to see what happens over time, especially as Intel wants it to be a server chip.
Of course, this could all be a big leadup to the announcement that Apple is going with the Itanium.
-Adam
When Itanium started, Intel was absolutely nowhere in 64 bit and high-end computing. Thanks to Itanium, over half Intel's competitors simply walked away from the market with little more than a few press releases from Intel.
Consider that at the time, you had Alpha (Dec), PA-RISC (HP), MIPS (SGI), and Sparc as leading 64-bit computing platforms.
HP in it's infinite wisdom was suckered the worst - giving up their own leadership position just to be strung along for many years in Intel's PR bluff. However Wall Street loved the "ooh, intel's story's so aWsUM that even HP is giving up" that SGI spun off and MIPS gave up on the high-end space; and Dec->Compaq->HP undervalued Alpha and it went away.
This has to be the most successful come-from-zero-to-wipe-out-half-the-market story in the history of computing. How can it be considered a failure.
Itanium is like the "Edsel" of cpu chips. It's too non-mainstream and while the geeks may ooo and ahh over its esoteric technical details, nobody really cares to actually buy one.
I was associated with porting a Java appserver onto Itanium a while ago (3+ years). Intel invested in this effort (free servers, access to hardware/compiler experts etc).
The problem was that, the JVM on this was very slow. It lacked JIT support and just crawled. Practically, speaking we would not have sold a single license on this platform. So, we decided to move away from being an early adopter to a market follower.
If not for Intel's premature marketing effort in engaging partners this early, we would have waited until a more stable environment was available, resulting in successful product shipping.
I talked to several presenters at an Itanium conference when I went to demo our product, I heard a similar story.
Well the reasons may not always be technical for such debacles.
Intel figured it was big enough to set the trend by making a radical change. It was wrong and paid the price when the market didn't follow. IBM thought it was big enough to set the trend by making a radical change with Micro Channel Architecture (replacement for the ISA Bus). It went nowhere and helped kill IBM's dominance of the X86 PC world it created. The fact that Intel didn't bet the farm and loose everything is either good planning or dumb luck on thier part.
*** Sigs are a stupid waste of bandwidth.
2. x86 is bad/ugly/dirty/whatever, however Itanium is not exactly clean either. The stacked register file is a good example of that. I personally prefer x86-64, which takes the evolutionary approach: fixes quite a few of the problems of x86, while still retaining the core features.
3. x86 chips do out-of-order execution; Itanium, OTOH relies on the compiler to schedule instructions and bundle them together. The main problem here is that doing instruction scheduling statically is much, much harder than doing it dynamically. An average program has a basic block size that is less than 10 instructions. It's very hard to find parallelism within such small basic blocks, so to be efficient at all, you need to do profiling to build traces/hyperblocks. In fact, profiling on the Itanium can give you a performance boost of 30%. However, profiling is hardly desirable from a software developer's perspective
The Raven
The decision to move instruction-level parallelization from runtime (in the CPU, hardware, expensive) to compile-time (software, cheap on a marginal cost basis) ended up being a poor one for general-purpose computing. You save silicon not having all the fancy instruction scheduling, reordering, etc., but you lose the knowledge of the runtime environment the hardware has when you move it into the compiler.
.NET bytecode to native code and Transmeta x86 to native VLIW) can do a better job because they can profile the running code and get a better handle on likely execution paths. These would be a good match to the VLIW Itaniums to compensate for them lacking that "complex" hardware to keep the execution units supplied.
Sure, there's a lot more processing you can do off-line in the compiler, but you also have a lot less information about how the code is actually going to be executed at compile time.
Theoretically, JIT compilers (Java and
The Itanium2 makes a good supercomputer chip because you can optimize your code very carefully and you've got a good idea what the data looks like and what branches will be taken, etc. at compile time.
Not so much respect as a "we have to" thing.
Itanium was supposed to be the new base chip, the thing to finally replace x86. Picture high performance and high volume, the other RISC guys weren't supposed to be able to compete. SGI and DEC cowered, shutting down ALPHA and MIPS.
HP decied they wanted in on Itanium early. They partnered with Intel on chip design. Intel designed the first chip, while HP's was the much more highly regarded Itanium II. They bet the farm on it, in some ways more than Intel itself, phasing out PA-RISC, and now trying to force people to move off of Vax and Tandem onto Itanium. They pretty much have no choice, having fired the other processor guys they had.
If you want to hear about respect, how about HP, the #1 Itanium vendor, killing off workstation class Itanium computers. If this isn't a white flag, resigning the chip into a nice market, i'm not sure what other interpretation there can be.
Let me tell y'all a little story.
Back in '94-'95 i was doing the third grade of the Computer Science course at the Royal Institute of Technology, which meant I had to choose a specialization. I chose "Computer Systems", ie. processors, busses, caches and what-not.
This was a very exiting time to be studying processors since (for a fleeting moment) Intel processors where the absolutely worst processors among the serious combatants.
Yes, you read that right. The Alpha was (of course) and unstoppable juggernaut, but through a freak act of development schedules the new MIPS had managed to outstrip the latest Alpha.
After MIPS and Alpha we had PA-RISC, SPARC, PPC and then finally the pathetic, lowly Intel x86.
Alpha had strong plans of totatlly replacing the x86 by offering Alpha based x86 emulations that were faster than the fastest x86 in running x86 code.
But now, Intel announced the Itanium.
Apparently, all the CPU makers sat down and discussed this, and agreed that "They may be last right now, but they have piles of cash. They could do this. They really could."
So, what did the competiton do?
Because of aquisitions, they also happened to be saddled with the best processor ever made, the Alpha.
Stick with dying Intel... Develop best processor. Hmm...
Well, you all know where HP is going.
And then what happend?
Intel didn't deliver... and didn't deliver... and didn't deliver some more.
Year after year passes...
When the Itanium was finally delivered, it was obvious that every other platform could have kept up, if they would just have kept developing their processors!
But they didn't and now they sleep with the fishes.
Conclusion: By making their Itanium announcement, Intel slew four out five serious competitor. It doesn't relly matter if the Itanium sucks. In fact, the Itanium would be Intels greatest success even if they had never delivered it.
I choose to remain celibate, like my father and his father before him.
Well, after you take the "Compilers" course maybe your love for IA-64 will have, uh, dimished a bit.
The VLIW architecture is beautiful in many ways, but creating a compiler that creates fast code for an in-order VLIW processor is a seriously difficult undertaking.
Well, a linker has little to do with CPUs or performance, they just glue modules together.
Wrong.
Having used Intel's compiler, I would think that you would know better. What about inter-module optimizations? Who's going to do that? The compiler or linker. It's the linker buddy. Optimizations aren't just source level. Once you have the assembly, there is still a lot of stuff you can do. Instruction reordering, vectorizations, etc.
Mad Software: Rantings on Developing So
The whole point of Itanium is that it doesn't deal with dependencies at all in hardware, thus making its scheduling very easy to implement (move these bits over here). It makes the compiler to all the hard work so it can just burn through instructions. Modern DSPs are pretty sweet, but 8 instructions per cycle is a luxury realized only because DSP is by nature a very repetitive exercise, so tons of resources can be poured into very sophisticated operations such as what you mention above. The pipelines aren't where Itanium's complexity lies. Instead, it is very feature rich elsewhere (supports both Endians, x86 emulation, etc.).
I'd rather be cycling.
Intel's still making mother boards. Their EPSD division is still a big player in the x86 server market.
http://intel.com/support/motherboards/server/
IANALBIPOOGL (I am not a Lawyer, but I play one on GrokLaw.)
sparc is no longer competetive. its major design win (register windows) turned out to be a liability long term. memory got faster, caches got better. register windows became obsolete, and sparc stopped scaling competetively.
powerpc is an overall better (faster, cheaper, more scalable) design than sparc. it doesnt make the same kind of assumptions as sparc did and thus powerpc was able to scale along with the rest of the industry as technology developed -- powerpc was able to take advantage of new developments in silicon without having to lug around old cruft; powerpc had few fundamental dependencies on the underlying technologies. sparc has baggage (register windows) which are no longer architectural wins.
powerpc assembler is really unpleasant to read and debug though. load/store is a pita. two instructions to load a single 32 bit value and _five_ for a 64 bit value(!). now consider that a compiler can completely reorder those instructions. not nice for readability.
One must bear in mind that "cute" is a relativistic function. As n (female population) decreases, the entire attractiveness bell curve moves a few notches to their advantage.
But seriously, it gets no respect because its a complete dog on anything other than vectorizable Fortran codes. Its inherent in the design.
The compiler has to do a LOT of work to pack instructions in to the VLIW(Very long instruction word). To get max performance I think you need to schedule 4? instructions in each word. You can do that with carefully written vectorizable Fortran with the help of a talented supercomputing class code tuner.
When you get to C and C++ it is nearly impossible. Pointers and pointer aliasing completely frustrate the compiler, and in general most C and C++ code don't have the vectorized nature of the class vectorized Fortran codes.
The IA32 emulation is inherently much slower than a Pentium or Athlon at the same clock and they have much higher clocks than the Itanic. So any application you carry a binary over from an IA32 box is a real dog. It takes advantage of none of the chips strengths and hits all its weaknesses.
IA64 has a place on some supercomputing applications that exloit its strenghts. On others I wager x386_64 is both cheaper(higher sales volume and easier to manufacture), faster and easier to develop code for. On any C or C++ code IA32 and x86_64 will win hands down.
With Itanium Intel was betting bumping up the clock on chips would run out of gas sooner than it did. They thought you would have to go to VLIW to keep increasing performance. Unfortunately clocks kept going up enough that the high end AMD and Penitum left it in the dust. AMD also developed x86_64 which gave people 64 bit address space which is needed for some apps, but PC prices and high clocks.
IA64 is doomed in any place other than niche supercomputing apps and its struggling there against Power, x86_64 etc.
@de_machina