Slashdot Mirror


Intel and HP Commit $10 billion to Boost Itanium

YesSir writes "Support for the high-end processor that has had difficulties catching on is coming in from its co-developers Intel and HP. 'The 10 billion investment is a statement that we want to accelerate as a unified body' said Tom Kilroy, general manager of Intel’s digital enterprise group."

64 of 272 comments (clear)

  1. Last Gasp for Big Iron? by ackthpt · · Score: 5, Insightful
    Last Gasp for Big Iron?
    So as I'm reading this there's a big plug for AMD Opteron just below the article. This would appear to me to be the threat to the Itanium, the same which effectively has killed big iron -- inexpensive commodity hardware. Sink a few thousand into Opteron systems and run what you already have, or sink far larger amounts into some gobble-de-gook system which won't run, except under software emulation, what your multiprocessor system does. Sorry HP/Intel and everyone else dumping money down this rabbit hole, I think you've lost the plot. Today's super computers are parallel computing down with 64bit Gen x86 processors, like the AMD Opteron. The glue is in the software, not in big fat chunks of expensive silicon.

    if still not convinced, i might have a few meg of core to sell you

    --

    A feeling of having made the same mistake before: Deja Foobar
    1. Re:Last Gasp for Big Iron? by dnoyeb · · Score: 3, Insightful

      In the words of The Gambler. "You gotta know when to fold em."

    2. Re:Last Gasp for Big Iron? by ackthpt · · Score: 2, Interesting
      In the words of The Gambler. "You gotta know when to fold em."

      It smacks of prior business arrangement HP, et al, agreed to back in days of yor, while Itanium was supposed to be "the next big thing", when Intel was telling everyone they wouldn't need the 64 bit CPU's AMD was gearing up to peddle. Intel's calling in all those promisory notes after making compilers and stuff available for so long. Having their druthers, I think everyone else would rather not.

      --

      A feeling of having made the same mistake before: Deja Foobar
    3. Re:Last Gasp for Big Iron? by countach · · Score: 3, Funny

      This aint time for Intel to fold em.

      This aint time for Intel to walk away.

      This is time for Intel to RUN RUN RUN!!!

    4. Re:Last Gasp for Big Iron? by Anonymous Coward · · Score: 2, Insightful
      I would have to agree with this, HP is now to tied into the chip to pull out. I think if they had the choice they would drop it but there have put so much money in and now they are going to dump more money into a CPU that is really quite far away from been what Intel said it would be.

      What Intel and HP need to do is admit that the chip is a waste and just let it die, like dumpy the waste man from Drawn Togehter you can hear the Itanium say "KILL ME"

    5. Re:Last Gasp for Big Iron? by timeOday · · Score: 3, Insightful
      Last Gasp for Big Iron?
      No, they must be planning to force it into the mainstream. They'd never recoup $10e9 just selling big-iron processors. Maybe they think a smaller manufacturing process will finally make Itanium affordable, or that more investment in compilers will make it work better.
    6. Re:Last Gasp for Big Iron? by ThePhilips · · Score: 5, Insightful

      > "Clusters are only really good for embarassingly parallel problems."

      You are overall sort of right about that. It's just science isn't standing still and most of new algorithms are specifically invented to be parallelized.

      Most problems of physics are solved with matrices. And matrices are of course are easy to parallelize. And physics - is the only who are buying most of big iron anyway.

      Nowadays, most of the weather prediction tasks, astronomical tasks, optical tasks, micromeasurements tasks are also optimzed for clusters - not big iron. It's not about top performace - it's about price/performance ratio. For the same money people can buy cluster with e.g. 10 times more raw performance to run unoptimal (e.g. 2-3 times slower) algorithms - but task are done quicker. And cheaper. Yeah, clusters have higher latencies - but they are still dominated by batch jobs, not interactive jobs. Big Iron has better interconnects - but the redundant interconnects take lion share of such system costs.

      In fact, the main reason why this have happened (clusters took over big iron) is the RAM prices. In my versity times (early-mid 90s), we all were occupied with shared memory problem: RAM was very expensive. Now people go to general store, pick several 1GB nics, pick several GBs of RAM, and pay a nickel for all that.

      Ask anyone in Computer Science now, everyone started throwing RAM at latency problems of clusters. It does look bad on paper and in theory. But in practice it just works.

      P.S. On-topic. IA-64 has great performance. But again, on price/performance scale it loses immediately to Intel's own Xeons and AMD's Opterons. Intel constantly refuses to amend its Itanic focus from features to focus on more affordable prices. The story line was quite well covered by The Register. Check posted links.

      --
      All hope abandon ye who enter here.
    7. Re:Last Gasp for Big Iron? by Fred_A · · Score: 2, Funny

      Just re-emerge them in 64 bit, duh!

      --

      May contain traces of nut.
      Made from the freshest electrons.
    8. Re:Last Gasp for Big Iron? by birder · · Score: 3, Interesting

      Just like when gambling, it's not the money already in the pot, that's already gone. It's how much you're willing to spend extra to get it. The pot odds don't look good to me.

      I've been a HPUX sysadmin for 9 years (help manage 16+ large servers). We started buying a number of Itanium boxes and have moved some apps to them. The IA64 chip is much faster than the PA-RISC, 40-60% improvements for us and overall cheaper to buy.

      However, the Opteron machines we have running Linux blow them away at less than half the price loaded up. I honestly don't see IA64 lasting another 2-3 years and I'm already making plans to migrate what we can from PA-RISC to Linux based machines instead of IA64.

      I really like HP-UX. It's not the most robust OS, but it's been rock solid for us over the years. Very, very, expensive like all closed Unix Vendors but for a large business it was money well spent at the time compared to Windows NT.

    9. Re:Last Gasp for Big Iron? by Courageous · · Score: 2, Insightful

      What I'm thinking is that AMD must be having a big party. If Intel is spending another $10B, sending good money after bad, one should think about what they are NOT doing. What they are not doing is spending that $10B on x86. This can only make their up-and-coming competitor quite happy.

  2. Alpha by linguae · · Score: 4, Funny

    Too bad HP won't spend $$$ to bring back the Alpha.

    I miss architecture diversity....

    1. Re:Alpha by MADCOWbeserk · · Score: 4, Interesting

      Couldn't agree more. Alpha was a great platform leaps and bounds above any of it's contemporaries in terms of speed. They were running at 125mhz when pentium 66mhz came out and got more done per cycle. The Compaq DEC merger hurt it badly, then the HP Compaq merger killed it. Itanic has always been a ponderous mess. Had Alpha gotten one tenth the R/D budget that Itanium got it would be server king.. Itanium (please don't try to prove me wrong with benchmarks) gets wiped by Power and Sparc, will die a lame duck kicking and screaming death.

      Could Jesus microwave a burrito so hot that he himself could not eat it?

    2. Re:Alpha by gbobeck · · Score: 3, Funny

      I also agree. I love my DEC Multia -- it does a great job of heating my room.

      More seriously, though... The Alpha was kicking ass and taking names back in the day. 64-bit and ran at 200 MHz when the Pentium was barely able to fart out 66 MHz.

      The funny thing is that most places just don't run Itanium chips - they use Xenon chips instead.

      --
      Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
    3. Re:Alpha by evilviper · · Score: 4, Interesting
      Too bad HP won't spend $$$ to bring back the Alpha.

      I miss architecture diversity....

      It seems to me, just about all the huge advantages that alternative architectures (like the Alpha) held over x86, have been washed away in the past few years.

      64-bit memory space. Insanely large cache. Very low-latency access to RAM. Incredible memory throughput. PCI-X/PCI Express slots on cheap motherboards. Seriously high-end graphics. DMA. SMP. Built-in 1000Mbps NICs. RAID. etc.

      What advantages could something like Alpha have over x86 now? A few years ago, I was anxious to jump ship to another platform, but with the introduction of the Opteron and kin, I'd say I'm quite happy with x86 now.

      The only feature I really want now is a new way to handle interrupts... Then simple things like copying CDs, or a little network traffic won't bring PCs to a crawl. Perhaps add a socket for an FPGA or other simple processor to specifically handle those tasks, like the math coprocessors of the old days.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    4. Re:Alpha by Quadraginta · · Score: 4, Interesting

      Well...my work (scientific computing) put a premium on sheer scalar speed, and for that the RISC architecture was great and the x86 CISC paradigm a drag. Once you learned how to write code in a certain way, DEC's compilers could make amazingly fast code out of it for the Alpha.

      In case you're wondering, no, parallel computing was never a good option. There's a large class of scientific problems that just don't work very well in parallel, because of large-wavelength correlations that make it painful in the extreme to write a parallel algorithm, if you can do it all.

    5. Re:Alpha by Quadraginta · · Score: 2, Interesting

      MD or MC simulation for systems with long relaxation times. My particular target was solution macromolecular conformational relaxations, e.g. polymer backbone twists and turns.

      See, with that big polymer backbone you can't break the system up into cells or anything, and you can't divide up the problem in the time domain, because of course what happens at t+dt depends very much on what's happened at t. So you're stuck, you've just got to do the simulation in a single thread.

      You can use multiple processors to better your statistics. That's just running the simulation over and over again from similar initial conditions, and since every simulation is fully indepedent you can just run them on multiple machines or whatever -- there's no advantage to any finer-grained parallelism. This is nothing to sneeze at, but it's still mostly just making nice smooth graphs for the publication.

      The kinds of stuff I was trying to do involved up to multiple millions of timesteps, to the point where I started to worry (in the MC case) about the random-number generator, ha ha.

    6. Re:Alpha by mcrbids · · Score: 2, Interesting

      If you think that the X86 platform has "caught up" with all the others, you are dead wrong. X86/32 or x86/64 does dead last in terms of total processing on any particular task. X86 is designed to do a large variety of tasks. Given a narrower scope, X86 gets blown apart by the likes of the Cell processor, used in the latest Playstation 3 in terms of total processing power - at the cost of genericity.

      The Cell processor is highly optimized for graphical output, while the X86 is a "workhorse" number cruncher and all-around get-it-done engine.

      The MIPS per transistor of the x86 is pretty low, as is the MIPS per clock cycle. So, if you want to run a mail server/Spam Asssassin/Greylisting on a system, use X86. But, if you want to produce realtimee graphiccs for video games, Cell is the way to go...

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    7. Re:Alpha by ooze · · Score: 2, Interesting

      I can give you a list of advabntages of other architecture over x86.

      - your already mentioned interrupt handling
      - effectively using Registers for argument passing
      - no need for real mode switch to access firmware/Bios
      - thread switches in less than 50 cycles
      - a memory table lookup in less than 50 cycles, or occasionally even COW and dirty pages flushing without table lookup at all

      Just compare the virtual memory handling and the interrupt handling and the parameter passing the task switch sections in the linux kernel for the different architectures. You will see the x86 versions for each problem to be by far the messiest and most manpower intensive and least maintainable versions. Several times worse. And when you compare the boot cose (which admitably only gets executed once though) it is a difference of several orders of magnitude. Hell, they even have a very own whole assembler in the Linux build tools just for writing those 20 instruction needed to boot it. Because no proper compiler or assemble would use those instructions anymore for anything.

      --
      Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
  3. tisk tisk by sardonic2 · · Score: 5, Insightful

    seems just a bit too late. they should donate to help feed some starving children not starving platforms.

  4. It's interesting to note that AMD will be close by by Nihilist+Hippie · · Score: 3, Interesting

    Disclaimer: I'm not hyping Northern Colorado as being "the next Silicon Valley". Intel is taking over the old Celestica plant next to the HP campus in Ft. Collins, Colorado, and AMD is looking to open up about 200 jobs in the same area (being Ft. Collins). Interesting move... http://circuitsassembly.com/cms/content/view/2709/ 94/

  5. Itanium vs. Ultrasparc T1 by ChrisGilliard · · Score: 2, Interesting

    Itanium has been taking share from both IBM power and Sun Sparc.

    True but can they compete with the UltraSparc T1 (which has 32 threads compared to Intel Itanium's 2 threads)?

    --
    No Sigs!
    1. Re:Itanium vs. Ultrasparc T1 by TubeSteak · · Score: 2, Funny
      but can they compete
      Of course they can.

      Dual Core = 4 threads
      Hyperthreading = 8 threads
      Quad Processors = 32 threads

      Ta Da!
      --
      [Fuck Beta]
      o0t!
    2. Re:Itanium vs. Ultrasparc T1 by Anonymous Coward · · Score: 2, Insightful

      Itanium is so low volume, how could it possibly put a dent in SPARC and POWER? When a person looks for a new computer to buy, Opteron is on the short list, followed by PPC and SPARC. Itanium? Okay, for physicists, perhaps.

      The UltraSPARC T1, if Sun can market it well, is the ultimate webserver, database server, and J2EE CPU. I'm extremely interested to see how many T1 servers Sun sells.

    3. Re:Itanium vs. Ultrasparc T1 by raftpeople · · Score: 2, Informative

      Itanium has been taking market share from Power????

      "Sales of IBM's Unix systems, called the pSeries, grew 15% in the first quarter and 36% in the second quarter--far outpacing Sun and HP. The trend should continue in the fourth quarter--historically, industrywide Unix sales have spiked 25% during this period--and into 2006, when IBM introduces a new high-end chip called Power5+."

    4. Re:Itanium vs. Ultrasparc T1 by ChrisGilliard · · Score: 2, Informative

      The T1 has terrible FP performance

      Yes, you're right about this. The T1 can only do a single thread of floating point ops at a time. This is why it's being marketed to the web/ap server market which don't do many flops. Sun is working on a new chip code named Rock which will address these issues. If I remember correctly rock will support 8 floating point threads at a time. It will also have some really awsome I/O lookahead features that allow a special 'thread' to read thousands of instructions ahead and look for I/O that can be started early. What the T1 is going to do to the Webserver market, Rock will do to the high end number crunching market.

      --
      No Sigs!
    5. Re:Itanium vs. Ultrasparc T1 by JonAnderson · · Score: 3, Insightful

      Well, the majority of commercial apps have 2% fp instructions. Sun didn't just stick a finger in the air and say let's build an integer only processor. If you look at the workloads that T1 is good at then look at the predominant workloads in procution today you will see that it covers pretty big 'niche' - in terms of revenue and volume. Niagara 2 will be even better at this (it will have a fully pipelined fpu per core for starters)

    6. Re:Itanium vs. Ultrasparc T1 by JonAnderson · · Score: 3, Informative
      Your logic is based around the concept that every task is highly parallel - they're simply not.
      Well, the server I am logged into right now has 358 processes running. Each of which has a least 1 lwp which equates to at least one thread. How many people have a server running one process with one thread?
      Even Sun don't claim that a T1 is comparable to an Itanium/Power/Sparc for tasks which need a few fast cores, which is why they use examples like Java application servers as the primary benchmark.
      Like specweb? like sap sd 2 tier? like Lotus notes? These are just the published benches.
      The Ultrasparc T1 is not a high-end machine, it's a low end one designed to compete against cheap x86 machines, I think the main surprise for me is that it's not available in a blade form-factor.
      Exactly. The T1 costs $26K in it's most expensive config (32GB DDR2) for a 2u system capable of beating out bigger, hotter Itanic, x86 and Power systems on certain workloads (contrary to what you think, those certain workloads represent a significant segment of what customers buy these types of machines to do). There are definite plans to have a blade version out this year.
      n 90% or more of workloads out there, a 32 thread core would have about 28 cores sat idle and 4 cores working flat out.
      Really? Thats sounds like total bollocks to me.
  6. Re:Why? by Blackhalo · · Score: 2, Insightful

    No, you're definantly not the only one. What is the value of a 64 bit single core, non 32bit backwards compatible procesor that generatates more heat per mip than a jet engine? I know Intel bet the bank on this architecture but good god, it's dead Jim.

    --
    "There is nothing to do it. But to do it." -Floyd Pepper
  7. Here is the problem by IntelliAdmin · · Score: 4, Insightful

    The chip was made to compete with "Big Iron" servers - the only problem is that it is marketed to the windows consumer market, and that is who looks at it when making purchasing decisions. AMD has really started to eat up this space, and if Intel does not start to turn this boat around fast they could really get hurt when 64bit CPUs are commonplace.

    1. Re:Here is the problem by PCM2 · · Score: 2, Insightful

      The marketing certainly has been a problem. I attended this Itanium press event, and correcting the marketing is certainly high on the agenda for the Itanium Solutions Alliance.

      What they want you to know now is that Itanium is not, repeat not a competitor for Xeon, Opteron, or the x86 architecture. Itanium's market is in high-end "mission critical computing" and as a replacement for RISC chips (meaning Power and Sparc).

      Where once they pushed the 64-bitness of the chip, the x64 extensions have muddied the waters somewhat, so they're not really talking about that anymore. What they are selling are the high-availability features that make Itanium competitive with the aforementioned RISC chips.

      The advantage they are touting vs. the competition is openness. If you want a Sparc system you have to go to Sun, and you have to choose from the Sparc systems that Sun offers and the support packages that Sun offers (or maybe Fujitsu, just to blur the point a little bit). With Itanium you have several suppliers -- including Fujitsu, HP, Hitachi, SGI, Unisys, and the other companies in the Itanium Solutions Alliance. Each of those is free to provide its own support packages and terms of service. You also have a few choices of operating systems, including Windows, Linux, and HP/UX, while the only OS that currently runs on Sparc is Solaris.

      Believe it or not, it's actually not that bad of a product story. Sooner or later, everybody who's on RISC chips right now is going to want to upgrade their hardware. If they're dead set against the x86 platform then they have three options. One option is to buy the latest version of whatever they're already using. A second option is to jump ship -- Sparc to Power or vice versa. Itanium gives them a third option, with the backing of Intel and a bunch of other prominent hardware vendors.

      And then there's always the other, more established Itanium market: running great big SQL Server databases. Believe it or not, there's a fair amount of people who want to do that.

      --
      Breakfast served all day!
  8. Short Intel now by countach · · Score: 4, Insightful

    >"Itanium has been taking share from both IBM power and Sun Sparc."

    Uhh, it could hardly lose share could it? If it lost any share the product wouldn't exist. What, did they double their share from 1 to 2 users?

    Ten billion is an awful lot to throw away on this loser chip.

    I mean, few people actually WANT to run a different chip (and thus a different OS and versions of apps) in their data centre, compared to their desktops. They used to do it, because it was necessary. Now it isn't necessary, so people don't want to do it. Intel's only hope is to try and get people to use it EVERYWHERE, on their desktops too. But there aint no hope of that either.

  9. The point is? by Sensi · · Score: 3, Insightful

    What's the point of running "Big Iron" and/or Itanium if we have to deal with hacks/patches and headaches to run real world production applications like SharePoint, SQL and other Office collaboration suites?

  10. Intel just removed 32bit hardware support by TubeSteak · · Score: 3, Informative
    http://www.digit-life.com/archive.shtml?2006/0125
    an Intel spokesperson confirmed that the Montecito platform, which will premiere the company's next-generation 64-bit Itanium architecture, will dispense with executing all 32-bit instruction set applications on-die, prompting customers to opt instead for software-based emulation which Intel promises will be faster anyway.
    The rest of the article is quite interesting. They claim that 32bit software emulation will outperform by "[greater than a factor of three]" their old hardware implementation.

    Anyone want to tie this into their $10 billion push?
    --
    [Fuck Beta]
    o0t!
  11. This is NOT it's last gasp. by Chas · · Score: 4, Funny

    This is more along the lines of post-mortem muscle contractions.

    I'm sure that SOMEONE out there is willing to pour money down the toilet for this platform. And they'll make HP/Intel very very happy.

    Then again, there's people who're into snorting drain cleaner too...

    --


    Chas - The one, the only.
    THANK GOD!!!
    1. Re:This is NOT it's last gasp. by Cloud+9 · · Score: 3, Funny
      Then again, there's people who're into snorting drain cleaner too...

      Please.

      Fortune 500 companies mainline.
      --
      Karma: Dyn-o-mite!(mostly affected by Jimmy Walker reading your comments)
  12. Let me get this straight by dgrgich · · Score: 4, Insightful

    Intel and HP spend untold sums of cash developing and rolling out a chip that comparatively few use. Thus, the market has effectively told them that there is not a large need for this behemoth. So how do they respond? A pledge to spend $10 billion more? How does this make sense again?

    1. Re:Let me get this straight by Jah-Wren+Ryel · · Score: 2, Interesting

      A pledge to spend $10 billion more? How does this make sense again?

      That ain't hard at all understand. Are you familiar with the term "minimizing your losses?"

      Intel and HP clearly believe that in spending $10B they will generate more than $10B in revenue. In other words, if they spent no more money at all, they would lose $X, now they expect to lose $(X+10B-Y) where Y is some number larger than $10B.

      --
      When information is power, privacy is freedom.
    2. Re:Let me get this straight by ceeam · · Score: 4, Funny

      To rephrase what somebody else wrote here:

      1) Profit!
      2) ???
      3) Itanium.

  13. Apple by apt_user · · Score: 2, Interesting
    Has anyone wondered what relationship Apple may now have with the Itanium? I understand they're liscensing some nice semiconductor IP from the now-defunct PowerPC G6 to Intel for future designs? Could this relationship be the breath of fresh air that the Itanic needs to float?

    "The history of science is cluttered with the relics of conceptual schemes that were once fervently believed and that have since been replaced by incompatible theories." -Thomas S. Kuhn

    1. Re:Apple by be-fan · · Score: 2, Informative

      The G6 would've been a POWER5 derivative. The POWER5 is a massively out-of-order RISC. Itanium is an in-order VLIW. They share nothing in common. The IP would've been useless.

      --
      A deep unwavering belief is a sure sign you're missing something...
  14. Tsk Tsk Tsk.. by ackthpt · · Score: 5, Funny
    seems just a bit too late. they should donate to help feed some starving children not starving platforms.

    How do you know they aren't planning this as some method of helping bring an end to wars? If they get the pentagon buying Itanium equipped missiles, just think what they could do!

    AFGHANISTAN - YBN Today it was confirmed that Osama Bin-laden was killed as a Cruise Missile, manufactured by Strongbad Industries asploded near his hideout. The Cruise Missile was equipped with an HP computer guidance system which employed an Intel Itanium processor. The missile missed the target, but Mr. Bin-laden was struck in the head by the processor's heatsink and died later from the injury.
    --

    A feeling of having made the same mistake before: Deja Foobar
  15. It is rather uninspiring to see all the negativity by Superfarstucker · · Score: 3, Informative

    Sure, it is a huge sum of cash and perhaps the 'shareholders' might get more short term benefit out of investing the same sum of money into commodity microprocessor R&D but the itanium could eventually pay off in a big kind of way. It seems that most people posting here are just as impatient as shareholders when it comes to results, they want them NOW! Good things can't always manifest themselves in a short period of time and I think it is impressive that Intel & HP continue to invest money into something that has yet to produce any tangible benefits over existing architecture. I'm willing to bet that x86 isn't the omega to processor design ideology, and itanium may not be either, but Intel & HP seem to believe it is a step in the right direction. Very few people that post here have the knowledge necessary to even begin assessing whether such a design may ever pan out and it appears the jury is still out among those who have the capacity to decide. Meanwhile Apple continues to recieve gratuitous praise for releasing shiny white computers with chamfered corners. Maybe if Intel & HP invested 10 Bn into cosmetic processor design they would be recieved more favorably with the press.

  16. Itanium isn't dead yet by cyberjessy · · Score: 2, Insightful

    In spite of all the negative publicity, Itanium is quite far from dead. The recent corrections in path make a lot of sense. What really put Itanium out of orbit was Intel's decision to use Itanium in even the small and medium systems. This meant lost marketing focus, and some lame architectural decisions for x86 compatibility. Itanium has nothing in common with x86 except its made by Intel.

    It seems the finally found the market:
    Last week Intel went back on x86 compatibility, only software emulation. Makes sense, the market for Itanium is big iron. It is way to expensive for anything less. And the users better run 64-bit Itanium optimized code to get their money's worth.

    Microsoft trashed all Itanium plans for the small and mid segment. They will support Itanium only where it makes sense in their product line, just Windows Server, .Net Framework 64-bit and Sql Server 2005. (Not in Exchange Server, Biztalk Server etc. Earlier we even had Windows XP running on Itanium. Sigh!).

    Intel's Motherboards supporting both Xeon and Itanium have now been postponed to 2009. This makes sense too, Itanium customers won't be interested in saving a few thousand bucks on commodity motherboards.

    And finally 10 billion $ pumped in; good news. I'd think Itanium will be back, by 2008. Architecturally, it is nothing to laugh at atleast. It is just that it lacked everything else, platform-compiler-apps support.

    --
    Life is just a conviction.
  17. Re:AMD64 by demachina · · Score: 4, Informative

    Its pretty good for vectorizable Fortran codes like those typically run on supercomputers, finite element analysis, computational fluid dynamics, crash codes, and 3D molecular modeling. These kinds of codes can be scheduled by compilers to take full advantage of the instruction parallelism in Itanic's EPIC instruction set. Itanic is a dog on most of the C and C++ codes most of the rest of the world uses on their computers because compilers have a pretty hard time scheduling four instructions in parallel at compile time on C and C++ codes.

    There is a market for Itanic in some traditional supercomputing applications but it is a relatively small market and never been a big growth market. I really doubt Intel and HP will ever recover the billions they've already sunk in to Itanic, let alone another $10 billion.

    I imagine the people at AMD are dancing in the streets at this news because Intel and HP are going to keep throwing even more good money after bad trying to salvage this dog. Its money that they wont be investing in R&D in markets that really matter.

    AMD can continue their push to dominate servers, workstations and desktops. If they could crack laptops, phones and embedded apps Intel would be in serious trouble.

    --
    @de_machina
  18. Re:AMD64 by jayslambast · · Score: 4, Informative

    Well, not in a small processor system, but once you start building larger and larger systems, Itanium (or Power5+) have the extra 'features' for error handling and reporting that an x86 don't have. Xeon and Opteron have the error handling of a fleet of 1950's cars. Sure they have alot of horsepower, but when they break down it stops running. You might have to drive the car a couple of more times to determine whether the car needs to be replaced. In a large computer system, this increases the down up time of a system. Itanium is like a BMW X3. Sure its a gas hog, and maybe a little less horsepower, but when it breaks down, you have tons of status lights to tell you what's wrong, and which processor is broken and whether the part is still good (a cache single bit correctable error) or needs to be replaced (mbe error on the fsb.) In large system, you can determine the source of the problem, whether it was an ignorable or replacible the processor error or a chipset problem.
    If any of you have ever put together a computer that has a bad part, its sometimes really hard to figure out what caused the problem. Systems that Itaniums usually go in have the error detection and error logging to exactly pinpoint where problems lie. This is the reason oracle DBs use these type of processors. It doesn't make sense for the common user to use Itanium, but companies like Amazon and Visa want these systems more for the reliability features than the speed.

  19. I hope this works. by megabeck42 · · Score: 3, Informative

    Truth be told, IA64 is a fantastically better architecture than IA32 or x86-64. Some of it's current caveats, for example, suboptimal software support and high costs, are not due to it's technical qualifications or drawbacks. Once the architecture reaches a critical mass and reasonable market acceptance, these issues should disappear. (more chips -> more people will target software for it, more chips produced in volume -> less cost per chip, etc.)

    It's other caveats, for example, poor compiler support, are issues that need to be considered carefully. I'd like to specifically address the poor compiler support. I am not concerned about this issue for the following reasons:

    1. Compilers can improve easily, with a recompile. If the architecture achieves a critical mass, then more people and organizations will justify the time and effort to improve compilers on the architecture. Not only can they improve, but taking advantage of such improvements would not require replacing hardware, which makes it an issue of time.

    2. The architecture is much more realistic about the guarantees that it's willing to make as a processor. One of the early complaints, was that initial generation of compilers for IA64 would generate, on average, 40% NOPs. It's important to consider a few details when regarding that statement.
    A. First, each clock cycle could allow the execution of up to 3 concurrent operations.
    B. Second, the architecture is not inserting extra NOPs transparently into the pipeline, as almost all modern processors do in the event of a pipeline data hazard. This fact can be viewed different ways.
    i. Most modern processors have to evaluate wether to insert a pipeline stall every single time that an instruction is executed. This is, essentially, wasted work because such a computation could be done by the assembler, however, it does spare the processor the burden of loading useless NOPs into the pipeline and the cache. On the other hand, minimizing the logic that a processor has to complete per cycle generally decreases the minimum amount of time necessary per clock (meaning that it could scale to higher clock speeds.)
    ii. The immediate question is, does reading all these NOPs out of memory cause a bigger hit to performance, than making the processor calculate the data hazards? Personally, I don't know. But, let's consider the idea for a moment. On both processors, let's assume that the instruction cache is fast enough to deliver data without wait states, assuming the cache has the data. When your processor is prefetching well, then the NOP issue shouldn't be a big issue. (Except for the fact that the NOPs will now be in the binary, making the binaries larger. I consider this a moot point given the inexpense of modern storage.) When your prefetcher can't anticipate correctly, though, I think the IA64 loses. Both IA64 and other modern architectures have branch predictors, so I suspect unanticipated branches which cause a pipeline flush (unavoidable) and unanticipated cache fills (unavoidable) will be mitigated roughly equally, But because the IA64 has longer instructions that aren't quite as dense, the IA64 will stall longer. Btw, I'm ignoring data stalls, to simplify my argument and because I don't think the architectural differences in the IA64 will significantly impact it. I'd enjoy being corrected on this point.
    The IA64 includes a predicate register, which stores the results of comparison instructions. Instructions in an IA64 'bundle' can be qualified to be executed conditionally, based on the condition of a certain bit in the predicate register. This allows the IA64 to avoid some branches. The compiler/assembler can pack a bundle which includes the appropriate two instructions, each qualified to execute for different states of the predicate register. Essentially, the processor is simultaneously issued the commands for both p

    --
    fnord.
    1. Re:I hope this works. by boner · · Score: 2, Insightful

      Let me disagree with you on a few points:

      ad 1: Compilers can improve easily, with a recompile. this remark I consider extremely naive and it really, really hurts your credibility. The fact that a compiler can be recompiled does not mean it also automatically improves its logic. The problem with all the compilers for Itanium is in the logic, not in the execution. Recompiling the compiler without improving the logic might give you a faster compiler, certainly not a better one.
      In order to improve compilers for Itanium the prefetch and scheduling logic in the compilers and assemblers needs to be vastly improved. Especially optimization for data-dependent branches requires a lot of additional work.

      ad.2
      A ... each clock cycle could allow the execution of up to 3 concurrent operations. Not if the compiler does a bad job, as many of them do now. Look at Itaniums performance on data dependent branches, it is underwhelming...
      B huh? Are you mixing up RISC and VLIW (EPIC) designs?

      ad.3 The only reason Itanium has good SPEC performance is because the benchmark is completely deterministic in its execution. Itanium greatly (like: insanely) benefits from repeated compile-execute-profile iterations of the benchmark. Real world performance doesn't come close. Only numerical codes with very well understood branches can hope to approach those SPEC rates.

      ad.4 I suggest the following literature first: Hennesey and Patterson, Computer Architecture (Morgan Kaufmann); Patterson and Hennesey, Computer Organization and Design (Morgan Kaufmann); Sima and Fountain and Kacsuk, Advanced Computer Architectures (Addison Wesley); Lilja, Measuring computer performance (cambridge); Jain, the art of computer systems performance analysis (wiley)

    2. Re:I hope this works. by megabeck42 · · Score: 2, Informative

      ad 1: Compilers can improve easily, with a recompile. this remark I consider extremely naive and it really, really hurts your credibility.

      Agreed. The point I was trying to make was that realizing the benefits of compiler improvements requires updating your software, not replacing the processor. Obviously, recompiling the same software isn't going to be an advantage.

      B huh? Are you mixing up RISC and VLIW (EPIC) designs?
      No, I'm not mixing them up. I was trying to compare their merits.

      Essentially, I tried to reason a guess to the following question.

      What would be the effect of removing the data-hazard protection from the chip and relying on the compiler to insert explicit noops? I surmise that a unpredicted branch will hurt more on IA64.

      Then I babble on for too long about different features. Sorry.

      Look at Itaniums performance on data dependent branches, it is underwhelming...
      This is unfortunate; do you know what is limiting the chip here?

      Itanium greatly (like: insanely) benefits from repeated compile-execute-profile iterations of the benchmark.
      Where, generally, does the compile-and-execute profile work improve things? Does it use the profiling output to hint the processor's branch predictor?

      Patterson and Hennesey, Computer Organization and Design - on the shelf, well worn and well read.

      I'll check out the others at the library.

      --
      fnord.
    3. Re:I hope this works. by twitchingbug · · Score: 2, Informative
      Agreed. The point I was trying to make was that realizing the benefits of compiler improvements requires updating your software, not replacing the processor. Obviously, recompiling the same software isn't going to be an advantage.

      Ah... but you see. this is the problem. improving compiler technology is extremely hard. Of course, the big hope in VLIW and EPIC architectures was that compiler technology would improve by some huge factor. This hasn't really panned out. Most code that we run is highly data dependent and branches way too frequently to parallelize anything. This is the same reason chips are moving to multiple cores now. It's hard to eek out that extra 3% single thread performance now - in chip or in the compiler.

      From your original post...

      Most modern processors have to evaluate wether to insert a pipeline stall every single time that an instruction is executed. This is, essentially, wasted work because such a computation could be done by the assembler, however, it does spare the processor the burden of loading useless NOPs into the pipeline and the cache

      uh this doesn't make any sense. Inserting nops for data dependencies/cache misses/etc doesn't "burden" processors. The only burden is if you happen to load your instruction stream with a ton of useless NOPs. Now I don't know IA-64 well, but somehow I doubt they removed all data dependency stalls - the instruction code explosion would amazing. your binaries would be huge.

      Look at Itaniums performance on data dependent branches, it is underwhelming... This is unfortunate; do you know what is limiting the chip here?

      data dependant branches - the hold back is that it's a serial stream of instructions. you can't parallelize code at all if each instruction is dependent on the instruction before it.

      Where, generally, does the compile-and-execute profile work improve things? Does it use the profiling output to hint the processor's branch predictor?

      no, you feed back the profiling information to the compiler, which will use loop counts and branch results to unroll certain loops, spend more time software pipelining heavily used loops, moving around basic blocks to reduce branching and increase block sizes. then you'll get faster code. Of course, it's not unheard of for intel or amd to make specific compiler optimizations to speed up SPEC. When I mean specific, i mean like very specific. if you see a unique-only-to-SPEC block of code, then compile into the nice hand optimized assembly. :P

  20. $10 billion? I don't think so by Shimmer · · Score: 2, Insightful

    Something smells fishy to me. $10 billion is alot of money for a marketing campaign.

    Assuming that each Itanium chip retails for roughly $1,000, Intel/HP could simply give away 10,000,000 chips for the investment they're making. Do they really think that there will be enough demand for these chips between now and 2010 to make up for that kind of marketing expense?

    I have a hard time believing they will actually spend anything near this amount on marketing, even if the campaign is successful.

    --
    The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
  21. In other news .. flogging a dead horse.. by flyingace · · Score: 2, Funny

    In other news .. flogging a dead horse, to cost 10 billion dollars.

  22. $10 billion all itanic chips ever sold?? by Devistater · · Score: 2, Insightful

    For some reason I'm thinking that $10 billion is probably more than they've ever made on the Itanic.

  23. Re:AMD64 by be-fan · · Score: 2, Insightful

    Well, that really depends on your perspective. It's great for people interested in doing advanced research on compiler technology, that runs our existing crappy C programs at the same speed on an architecture that makes life harder on the compiler. It sucks for people who are interested in doing research on compiler technology to make higher-level languages more competitive with low level ones.

    I don't see the point of writing a super-compiler that can schedule C code at compile time, when processors can do that just fine at runtime. I think its far more interesting to focus on writing super-compilers that can make high-level languages perform better.

    --
    A deep unwavering belief is a sure sign you're missing something...
  24. Performance by velco · · Score: 4, Interesting

    Itanium2 systems are among the top in transaction processing
    http://www.tpc.org/tpcc/results/tpcc_perf_results. asp?resulttype=all
    and THE top one for clusters.

    It makes sense for such an inventmen to go to
      a) improving the fabrication facilities - achieving lower defect rates
            and reducing price;
      b) improving the fabrication process - aiming at higher clock rates

    Remember also the recent announcement that an Itanuim CPU will no longer contain essentially a whole IA-32 CPU.

    ~velco

  25. ITER? by Xoknit · · Score: 3, Interesting

    10 Billion? That means it is just as important to humanity as nuclear fusion? WTF?

  26. AAAARRRRRGGHHHH!!! by wjeff · · Score: 2, Interesting

    This just makes me insane, I know it was already mentioned several times that people wish HP would put this kind of effort into reviving the Alpha. But to read about them putting this much money into a piece crap like that Itanium after the way they chucked out the Alpha, is expecially galling when you consider that in HP's own internal testing, Alpha EV8s and 9s consistently wipe the floor with even the latest Itaniums.

    --
    my old sig is obsolete, and I haven't come up with a stupid enough new one yet
  27. Re:Ah, capitalism. by Gwala · · Score: 2, Interesting

    Is there really a $140 billion dollar opportunity here? Does Itanium really offer something so superior to other available platforms that its creators are justified in believing they can acquire a large fraction of the market?

    Yes. Absolutely killer parallel performance.

    For certain tasks (such as matrice operations), it can do one operation, simultaneously on 100 registers (the Itanium has around 300 registers), it's pretty specialised, but for certain tasks, it can be a speed demon.

    A lot of the performance griping was caused by either, the 32-bit X86 emulation, which was always ridiculously slow, or, using it as a general purpose processor, not the specialised one it is.

    I always thought of it as a niche architecture however, I'm not quite sure why Intel's throwing so much money at it.

    --
    #!/bin/csh cat $0
  28. Aw, jeez... by NerveGas · · Score: 3, Insightful


        AMD is starting to kick Intel's pants in the most lucrative arena, small- and medium-sized servers. Instead of trying to compete technologically in that area (as opposed to just marketing), they're throwing good money after bad into a failing/failed architecture which only makes sense for a few highly-specialized applications. If it weren't for the fact that most holders of Intel stock know next to nothing about the industry, I would expect a cry for a change of leadership.

        Sure, there are a few supercomputing-type applications where the Itanium really, really shines - but they're sufficienty specialized that Intel just doesn't move a very large number of CPUs.

        Like I've said before, Intel is in a bind because of its own laziness and arrogance. Look at one of the primary advantages of the A64/Opteron architecture - the on-die memory controller. More memory bandwidth, lower latencies, and a memory subsystem that scales with the number of CPUs. Big-iron vendors proved that technology long before AMD decided to use it. Yet Intel has always enjoyed the superior manufacturing side of the business - if *anyone* could afford to have put those extra transistors on the die, it was Intel. Since they're almost always a step ahead of AMD in making smaller transistors, they had the *ability* to do something along those lines long before AMD did - but relied on the old tradition of more megahertz and lots of marketing. I don't think that this move is much different, they're putting their efforts in the wrong direction.

    steve

    --
    Oh, you're not stuck, you're just unable to let go of the onion rings.
  29. Intel is up to something... by syncrotic · · Score: 4, Interesting

    Recently an article was published on anandtech that puts the itanium in a new light: it's actually very efficient in terms of die area utilization. Combine this with Intel's recent announcement that they were scrapping the hardware x86 compatibility on the itanium, which takes up a fair bit of die space, and you have a very small core of the sort that's absolutely perfect for multi-core applications.

    Itanium needs a lot of cache to function well, for reasons that the aforementioned article describes, but it's not unreasonable to assume that intel's shared cache technology from Yonah will make its way into Itanium.

    This thing might be trying to compete with chips like the Ultrasparc T1.

  30. You know... by Stan+Vassilev · · Score: 3, Funny

    there's a typo: Intel and HP commit 10 billion to booze and women, that's the title, I have no idea what this "Itanium" thing is and where it came from.

  31. people dont buy it by NynexNinja · · Score: 2, Insightful

    The chips are way over priced and too under performance for people to spend the money. No marketing campaign can fix that.

  32. Itanium is a great processor by Theovon · · Score: 3, Insightful

    People like to talk about how Itanic, as it were, is a flop. It is, but not because it's not a good processor. Itanium is a very cool architecture with features long-time in coming. For instance, used properly, branch predication can be a HUGE boost to performance, and it's proven itself to be so when used properly on the Itanium.

    The first problem is one of marketing. HP/Compaq is a screwed-up company, the merger of two wholy incompatible companies that could never work together properly. Put this together with the fact that they canceled Alpha, another great processor, and you can see that selling Itanium is more about politics than engineering. The next problem is pricing. For a single-chip solution, Itanium is awesome, if you don't count the fact that you could buy multiple Opterons for that price and achieve more performance with properly threaded code.

    There are, of course, technical problems. Itanium is a heat monster. They didn't design it with power consumption and heat dissipation in mind. Did you know that the Itanium's top speed isn't limited by wire delays like it is in most other chips? No. It could actually run a lot faster, were it not for the fact that they can't get the heat off the chip fast enough. Another problem is the compilers. Static scheduling has its limitations, but the real limitation is that Itanium compilers can't manage to do even decent scheduling. It's too complicated. Much of Itanium's performance is theoretical. Given a small piece of C code, you can recode it in assembly and get it to run 10 times faster. If only the compilers were as smart as the assembly coder.

    Itanium was a great idea. It's just being executed poorly, and the R&D is being put into the wrong place. The architecture is there. It's great. Now, get the price down, design it for lower heat dissipation, and get some people working on that damn compiler!

  33. My guess on direction by ebrandsberg · · Score: 2, Insightful

    Consider: One of the compiler issues has been the ability to schedule all four pipelines with instructions that are useful, instead of no-ops. Now, consider using a method like the T1 does, where you have four sets of VLIW threads, each with on average 3 instructions. You could get away with executing the four threads with 12 pipelines on average. In effect, you can take the no-ops from one set and fill them with instructions from another thread, and keep the pipelines chugging. If tied together properly, it would have binary compatibility with current Itanic code, make use of today's ineffecient compiler generated code better, and make the arch work much more effeciently with OS threads ala the Sun T1. Given that the overall core (not including x86 and cache) for the Itanic is fairly small, something like this could probably be done very effectively and push the Itanic ahead.

  34. Don't forget what happened to Digital's AXP/Alpha by gd23ka · · Score: 2, Interesting

    If someone is really dumb enough to throw money down that toilet I just hope they remember to flush often between handfuls of bill. Sorry to see IA64 go without even ever having had a chance at it, but even viable 64-bit veteran architectures like the Alpha have gone down that drain.