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."

272 comments

  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 evilviper · · Score: 1, Insightful
      Last Gasp for Big Iron? [...]
      Today's super computers are parallel computing down with 64bit Gen x86 processors, like the AMD Opteron.

      Clusters are only really good for embarassingly parallel problems. The interconnects just can't be as fast as a local bus.

      How's this for an alternative: "Commodity Big Iron"?

      Why can't a supercomputer be based largely on off-the-shelf CPUs, RAM, Drives, etc.? I know important pieces are missing, but it should be possible to open this stuff up, and have it become a commodity.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    7. Re:Last Gasp for Big Iron? by Anonymous Coward · · Score: 0
      Itaniums big benefit is it's floating point performance. This makes it's target audience the financial and scientific communities. Most of the types of applications which are worth throwing itanic amounts of money at (data analysis, decision making, forcasting, monte carlo simulations, etc) tend to work well in parralelized computing platforms such as grids and clusters. It's going to be much cheaper in terms of hardware, cooling and power to set up a grid rather than some phantom mega cpu itanium machine.

      I think Sun actually got it right this time with their chip multi threading approach. The US T1 is great for applications that run multithreaded such as DB's, webservers, java app servers, etc. Floating point operations aren't great since there's only one floating point unit between the 8 cores. Rock is coming out soon and will have 8 fpu's and better i/o proccessing. If Rock is as energy efficient as the T1 itanium is toast. A cluster of opterons will even do a better job than itanium much cheaper and you'll have a wider variet of applications to run on them.

    8. Re:Last Gasp for Big Iron? by drgonzo59 · · Score: 1
      Would I really want to buy it, just so I can run all the programs I have in software emulation mode? -- I think I'll pass, I'd buy another Opteron instead...

      It seems Intel and HP are like the macho guy who is lost and is obviously going the wrong way, but rather than admitting he made a mistake he keeps going further.

    9. Re:Last Gasp for Big Iron? by Stalks · · Score: 1

      Wouldn't it be a waste of money to buy a top-end 64bit processor if all the programs I have run 32bit?

    10. Re:Last Gasp for Big Iron? by Anonymous Coward · · Score: 0

      It's far too easy to say HP/Intel are wasting money. I don't think they would do so if Itanium was dead. Of course, people prefer to think of Itanium as a big fiasco, as well as IBM people do, always posting news saying HP is dumping Itanium or so ...

      Maybe HP/Intel were fed up with that and decided to announce this $10 Billion to make people understand it is clearly not the case.

      But anyway, look at top500.org as well as TPC-C/TPC-H best scores and you will perhaps finally understand that Itanium is well represented. And also you will figure out why IBM wants so much to kill Itanium.
      There has been lots of Itaniums which has been sold. Not just a "couple" of machines here and there ...
      So, please, stop this I-thought-itanium-was-dead thing ... It's not going to happen. Even within 5 years.

    11. 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.
    12. 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.
    13. Re:Last Gasp for Big Iron? by prefect42 · · Score: 1

      I think you're very wrong on your last comment. You look at the computers currently nailing the top500 and it's Blue Gene. #1, #2 are both Blue Gene based machines. If you've seen the architecture of those machines, they're anything but generic 64bit x86. The density of these things is amazing, just look it up. You're looking at thousands of processors per rack.

      Also, you can get some pretty cool (ahem) machines running Itanium (SGI Altix for example) running 512 processors and 128Tb RAM in a single image. Combine that with an interconnect that provides well under 1 microsecond latency (up to 6.4Gb bandwidth) and you've got quite a fun machine.

      But you're right, if you don't need anything exotic, don't buy it.

      --

      jh

    14. Re:Last Gasp for Big Iron? by Jeff+DeMaagd · · Score: 1

      The glue is in the software, not in big fat chunks of expensive silicon.

      The software doesn't necessarily work so well for efficiency. Even the Opteron systems need "big fat chunks of expensive silicon" to run more than eight physical processor chips (currently, 16 cores).

    15. 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.

    16. Re:Last Gasp for Big Iron? by Anonymous Coward · · Score: 0

      I am curious about parallelization of matrices. Some methods like Gass-Seidel iterative methods whose results actually depends on the order of computation are difficult to parallelize, but what about Gaussian elimination, the basis of much of linear algebra. Is there any parallel version, especially with pivoting which is a must for any reliable results.

    17. Re:Last Gasp for Big Iron? by MonaLisa · · Score: 1

      There is definitely a place for high-end server processors, and for the last few years IBM and Intel have been leapfrogging each other with the POWER4/5 and IA64. Unfortunately for Intel, when the POWER5 appeared, IA64 was left behind. The TPC-C benchmark http://tpc.org/tpcc/results/tpcc_perf_results.asp is a big deal, and HP lost the lead when the POWER5 servers appeared. My guess is that HP+Intel (along with NEC, Unisys, Bull, and others who also make >= 32-way IA64+Windows Server machines) want the IA64 to be competetive with the POWER5, hence the $10B investment. I have no doubt they can pull it off. The x86-64 processors are great for some applications, but the large transaction processing server is not one of them. If support for the IA64 is withdrawn, then IBM will be alone at the top - and they certainly are NOT abandoning big iron any time soon. There is too much money to be made in TPC.

    18. Re:Last Gasp for Big Iron? by fitten · · Score: 1

      Yes, since matrices form the basis for a lot of the computation for the types of problems parallel computing wants to solve, parallel matrix solution algorithms are all over the place. There are a number of algorithms even based on properties of the matrix, even.... dense vs. sparse. There are algorithms based on the amount of communication required, as well. Some algorithms work better with fast interconnects, some tollerate slower speed interconnects. The same with latency. Some Google-Fu can turn up a bunch of stuff.

    19. 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.

    20. Re:Last Gasp for Big Iron? by supradave · · Score: 1

      Perhaps there are some applications that could possibly benefit from the Itanium's better security model.

      Itanium isn't x86, so comparing it to x86 is pointless. Itanium isn't going to replace x86. I work for a company that writes for the Itanium and we know that. But we can certainly do things on Itanium that x86 can't do.

      Gee, to sink 10 billion in to a 'dead' chip makes me think that maybe it's not as dead as people with x86 on the brain think.

      Though I can't wait to get an Intel Apple.

    21. Re:Last Gasp for Big Iron? by joshmccormack · · Score: 1

      I don't know... I'm no mainframe guy, but I've seen guarantees of the impending doom of big iron for a decade now, and they still seem to be chugging along. Reliable, can segment them, run other OSes ontop, good history... it's going to take some time for other options to get the history needed for people to chuck the iron.

    22. Re:Last Gasp for Big Iron? by poofyhairguy82 · · Score: 1
      Wouldn't it be a waste of money to buy a top-end 64bit processor if all the programs I have run 32bit?

      Not really, because with the dual core AMD CPUs the 64 bit part is "free." Since these CPUs are faster than Intel's 32 bit processors (with 80%+ of applications) then you pay no premium for 64bitness. Its there if you want to use it though...

    23. Re:Last Gasp for Big Iron? by ackthpt · · Score: 1
      I don't know... I'm no mainframe guy, but I've seen guarantees of the impending doom of big iron for a decade now, and they still seem to be chugging along.

      Just very, very few of them left. Most enterprise systems are becoming multi-processor build around Pentium and AMD64 variations. Where I worked in 2000 they scaled back from 3 to 1 and are likely soon going to be running on Pentium(Xeon) or AMD servers.

      Reliable, can segment them, run other OSes ontop, good history... it's going to take some time for other options to get the history needed for people to chuck the iron.

      Oh, no doubt, these were rock-solid systems! I truly miss working on them, but they cost HUGE amounts of money and absolutely required an expensive field service contract with fast response.

      In short, the commodity hardware has been a cost cutter's dream, even if you could only do it once. Unfortunately along with the deaths of many big iron manufacturers so has gone the way of getting decent field service.

      --

      A feeling of having made the same mistake before: Deja Foobar
    24. Re:Last Gasp for Big Iron? by Anonymous Coward · · Score: 0

      >>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..

      You're missing the point of the article. It's not about super-computing. Not all problems require a super computer and not all problems lend themselves to parallel processing.

      In the past year, we've purchased about a dozen Itanium base HP servers. Why? Because they were the best option available to us. Note, I said beat option and not that they were the best. Corporate policy is that HP is the vendor of choice for Enterprise class hardware. As such, our choices were PA-RISC or Itanium. Given that HP had announced the end of the PA-RISC family, choosing Itanium was a no-brainer. So far I'm satisfied with the choice, since our application runs well on Itanium and the performance is better than it was on 1990s vintage Ultra Sparc servers.

    25. Re:Last Gasp for Big Iron? by Cheeko · · Score: 1

      Except that many many of these systems (the vast majority) will not be used for High end technical computing. They will be used in various business functions. I imagine billing, financial services, and DB work will be high on the list. Transactional processing is something we see in lots of the press material with regard to these. A large number of these tasks are still run in a serialized manner, which ends up needing large NUMA style machines. Until the tasks are parallelized, the renderfarm model of lots and lots of cheep systems won't work for many of these applications.

      While you are correct with the matrices and such, the migration to a parallel algorithmic solution to many of these business cases hasn't happened yet. And until it does there is still a large amount of money to be made on these types of systems.

    26. Re:Last Gasp for Big Iron? by Bing+Tsher+E · · Score: 1

      There is always a performance cost in running 32 bit software on a 64 bit platform. No amount of handwaving will make that not the case. Saying 'it is faster than running the 32 bit software on 32 bit hardware' is ridiculous. You're comparing 'the new stuff' to 'old stuff.' And you sound more like someone from marketing than anything else.

    27. Re:Last Gasp for Big Iron? by Bing+Tsher+E · · Score: 1

      Or, it could be making them nervous. Really, if all AMD can do is cling to something (the x86 'clone' architecture) then they should be getting nervous. The industry needs a clean break from x86. It has for years.

      The opinions of a bunch of people who buy bare motherboards and consider themselves 'hardware wizards' because they know how to spin a phillips screwdriver is irrelevant.

    28. Re:Last Gasp for Big Iron? by Courageous · · Score: 1

      The word 'need' does not mean 'in my studied opinion, they ought to'. It means 'need'. Industry does not need this. Industry doesn't feel or know of any such need. To the contrary, there is a lot of need to the contrary, as in needing to not have to buy all the software over again during a switch. AMD wisely continues to recognize this.

      C//

  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 Anonymous Coward · · Score: 1, Funny

      I miss architecture diversity....

      Come to the other end of the spectrum, we've still got ARM.

    5. 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.

    6. Re:Alpha by Anonymous Coward · · Score: 0

      There are plenty of reasons to prefer a true RISC or EPIC core to an x86(CISC) core. Continually the most important of these is in the processor itself. Right now the Pentium 4s and Athlons invest a huge number of transistors to coming up with useful microcode (RISC instructions) to be executed in their pipelines. RISC and EPIC both eliminate this piece of real estate. The removal of such transistors allows for one of several options:
      1) decreased die size
      2) increased cache
      3) increased functional clock speed
      4) improved look-ahead projections
      5) lower power consumption
      6) better heat dissipation
      7) shorter functional pipelines
      8) other things I'm not immediately recalling

      Many of these are not mutually exclusive, and many of them require their own full explaination as to why they are included on that list (e.g. shorter functional pipelines), but all of them would be an improvement.

      Also with a move to full RISC this multi-core/multi-thread chaos becomes a lot easier to deal with because the microcode generator doesn't get in your way.

      Of course these are the same advantages one gets with an ARM core (RISC), and explains why all our phones basically have an ARM core.

    7. Re:Alpha by Anonymous Coward · · Score: 0

      I'm curious, which classes of scientific problems require a lot of scalar horsepower and don't scale with additional processors? I'm not doubting you, I'm genuinely curious because it's outside my experience -- molecular modeling and quantum chemistry problems appear to scale very well.

    8. Re:Alpha by cciRRus · · Score: 1
      Too bad HP won't spend $$$ to bring back the Alpha.
      Does that mean that HP is now concentrating on Beta instead?
      --
      w00t
    9. 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.

    10. Re:Alpha by ppanon · · Score: 1

      Hehe, Beta late than never.

      While that sentence may bring to mind the Itanium, I suspect that "never" might have been an improvement for such an EPIC disaster. Oh well, I remember in 2000 being skeptical of Intel managing to succeed with EPIC where 80s VLIW vendors had cratered. I also expressed serious criticism about how the P4's very long pipeline would get slaughtered on stalls from branch mispredictions, and how it would be hard to supply the peak memory bandwidth needed to keep the beast fed with data and instructions as the clock rate went up to try to make up for the expensive stalls.

      Then again, in January 2003, I was also suspicious of the validity of the reports of WMDs coming from Iraqi refugees provided by Chalabi's group after I heard he was wanted in Jordan for multi-million$ fraud in the failure of his bank. Clearly this was a man who was willing to prepetrate swindles on a large scale.

      You're ignoring me again. Stop thinking about how much fun you have when you talk on your cell while driving your SUV because everybody with a survival instinct gets out of your way and Pay attention dammit!

      --
      Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
    11. 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.
    12. Re:Alpha by MisterQ · · Score: 1

      If this wasn't so sad, it would be funny.

      I am consulting to a very large corporation, about technology direction... They thought of themselves as a "Sun" Shop, and by the way, they outsource a large amount of their operations to CSC, and aren't impressed with their track record. They are also moderately unhappy with their Sun Platforms, and considering a change in the next 18 months. Do I have a strange sense of Deja Vu here?

      A real audit, turns out that the bigger slice of their in house technology is actually running on Vaxes (OpenVMS) and has been ticking along forever with little or now maintenance.

      Just a day or two ago, I spotted something that indicated that HP was considering buying into CSC to strengthen it's service arm, Yet this was what CPQ bought DEC for. It had it's faults, but DEC did a lot of things right...

      Which also brings me to Alpha. HP pulled the Pin on EV7.9, EV8 could ship now, it was done, ready in the bag, set to rock and roll. It was an eight-way, superscalar, multithreaded engine. Still streets ahead of the competition. Sitting behind it, perhaps several months of design effort remaining was the Ev9. Specs for this talked about 16 on-chip RAMBUS channels, and 77 Gflops per CPU.

      EV10, and Ev11 generation designs were already in the works, when the plugs were pulled.

      (This is one of the things i loved about DEC (I worked there) - their forward thinking in the technical side. Alpha was designed with a REAL 30 year life span. I was working in the labs on VMS V5.last and VMS 6.0, VMS 6.1 and 6.2 and 6.3 were already in varying stages of development (showing a forward plan that had structure, rather than the reactive crap we see today...) Heck, their storage folks were thinking about SANs back in the mid 80's.

      If Hurd has an ounce of brains, he would gamble about 1 of those 10 Billion dollars on restarting Alpha. Engineers would come out of the woodwork, and sacrifice their souls to work on it. Customers would flock back to them. They wouldn't need to "buy" a services arm (again)....

    13. Re:Alpha by Anonymous Coward · · Score: 0

      You're ignoring me again. Stop thinking about how much fun you have when you talk on your cell while driving your SUV because everybody with a survival instinct gets out of your way and Pay attention dammit! I wish I could mod you -1 what in the name of jesus h tapdancing christ on a grilled cheese sandwich are you talking about

    14. Re:Alpha by evilviper · · Score: 1
      We aren't talking about general-purpose vs custom chips. We're talking about x86 vs. (eg.) Alpha. Multipurpose chip vs multipurpose chip.

      But, if you want to produce realtimee graphiccs for video games, Cell is the way to go...

      That's nice and all, but I don't want my x86 processor to render videogames... I want my videocard's ASIC to do that. Videocards are getting very impressive, particularly in comparison to consoles.

      Who knows, maybe in a few years, we'll have some variation on cell processors built right in to videocards.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    15. 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.
    16. Re:Alpha by jcr · · Score: 1

      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.

      And then a bunch of those guys went to work at Intel.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    17. Re:Alpha by gbobeck · · Score: 1

      Didn't a few of the people who worked on the Alpha chips work for Samsung too?

      --
      Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
    18. Re:Alpha by evilviper · · Score: 1
      Right now the Pentium 4s and Athlons invest a huge number of transistors to coming up with useful microcode

      "huge" doesn't tell me much. Would you like to attach a number to that? I don't follow CPU development closely, but it is commonly said that the instruction translator is now really quite tiny and insignificant in comparison to the rest of the chip. Sources would be welcomed.

      1) decreased die size
      2) increased cache

      See above. If it's only a difference of 0.5%, there's no reason to worry about it.

      3) increased functional clock speed

      Reality hasn't borne this out. RISC processors have been clocked much slower for many years now. The final Alphas were clocked at about 1.2GHz when AMD/Intel was up to 2GHz. Look at Power or SPARC processors, and you don't see high clock speeds.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    19. Re:Alpha by C0vardeAn0nim0 · · Score: 1

      "they use Xenon chips instead."

      the reason why ppl would use videogame consoles for serious server tasks realy escapes me...

      oh, you meant Xeon, right ? sorry, move on, nothing to see here...

      --
      What ? Me, worry ?
    20. Re:Alpha by hr+raattgift · · Score: 1

      Never mind using the Cell's SPUs as shader engines -- your GPU will do that job just fine. What you want the SPU for is any streaming single-precision floating point workflow with multiple stages or parallel streams. The throughput ought to be much better on Cell than other high-end processor architectures, leading to an earlier finish of such a workflow. Time is money.

      One obvious application is rendering and compressing. The Cell will let you pass the output of one SPU's miniprogram to the input of another's, so you can have the SPE process I/O and feed raw data in and out of a bunch of SPUs it sets up to cook the data. A set of SPUs can do the cropping, scaling, static denoise, temporal denoise, gamma adjustment and compression while another set of SPUs can adjust audio volume, dynamic range and compression. This approach would blow the socks off a fast standard core + single SIMD engine. A dual core on the same die would give a speedup of course, but given the heavy streaming floating-point activity the second PPE-equivalent might not be helpful compared to the second SIMD engine, and here you have two and not eight as in the Core. A multi-die solution giving 8 SIMD engines (and 8 cores) by comparison pushes at the limits of inter-package and memory bandwidths -- the Core's EID interconnect is amazingly fast.

      Lots of Apple's pro apps (Final Cut et al, Logic et al) are used by people with workloads that would benefit from the Cell architecture by finishing a particular job earlier than on a multi-PPC or multi-Intel system. The two-issue/dual-thread in-order restrictions on the PPE won't be a problem for apps compiled and scheduled for the Cell -- Universal Binaries and gcc 4.0.1's Apple-specific -fast flags can do this easily.

      Meanwhile, code built for Motorola G3s, Moto/Freescale G4s and IBM G5s (including VMX/Velocity Engine code) will run on the Cell's PPE without recompilation, but not as quickly as code explicitly (re)built for the Cell. Whether it would be *too* slow is an interesting question.

      In principle, system performance on dedicated-use media processing workstations built around the Cell would be somewhere between fine and exceptional depending on how much the code relied upon VMX (aka Velocity Engine or Altivec). Worst case performance would occur when running lots of applications scheduled on much older PPC implementations, so simply booting a disk filled with apps built years ago would be the least optimal (but still working) start to a Cell system.

      Slow but essentially full backwards compatibility is possibly a curse rather than a useful feature. It was for Itanium. Some of that is that most of the pressure to supply a processor-specific optimization of an application that works on the new processor is removed.

      Apple is relying upon software ISA-to-ISA translation on the new Intel Core Duo systems, and the Cell likely would in all cases outperform Rosetta-on-Core-Duo in terms of speed and moreso in terms of running SIMD code, and compatibility issues like giving non-garbage results to exception routines...

      A recompile into a Universal Binary probably would give the advantage back to an Intel Core Duo over a single Cell especially for multi-threaded apps using little SIMD. Heavily SIMD-using code would likely favour the Cell even if only the PPE's VMX was being used. The Cell would almost certainly beat the Core Duo for all tasks dominated by floating point operations, provided those operations were performed by the SPUs.

      If Apple ever seriously considered the Cell architecture for market segments that do lots of real work dominated by floating point performance, it would be pretty clear that a smart thing to do would be to have most of the floating point code be hidden in Apple-supplied frameworks (libraries) tuned for particular processor implementations (e.g. the Core Duo, PPC 970 and Cell). Mac OS X already mostly does this with (among others) its Accelerate, QuickTime and Core* frameworks.

      The

    21. Re:Alpha by renoX · · Score: 1

      Well if memory serves, the new Itanium will removes their x86 and use software emulation instead.
      That said I don't think that this will improve their performance much: I bet the problem is more in the man-month needed to maintain this part than about the transistors used.

    22. Re:Alpha by renoX · · Score: 1

      >What advantages could something like Alpha have over x86 now?

      Have x86 caught in the SpecFP?
      RISCs or Itanium tended to spank x86s on FP computations due to better memory subsystem (this is no longer an advantage) and to better FPU (here I'm not sure that x86 have caught up).

    23. Re:Alpha by Jeff+DeMaagd · · Score: 1

      Maybe it's just a joke, but I think people need to give it up. I own an Alpha but haven't used it in a couple years. I am not going back to it either.

      Unfortunately, whether or not the tech was at fault, they aren't coming back. It costs an excessive amount of money to develop a chip and far more to develop and maintain the software that uses it to justify so many architectures. I mean, in something similar, I wish that Matrox was "coming back" because they have features I'd actually use, but the expense in maintaining a competitive 3D gaming chip is simply too high, so they had to specialize. Which is too bad as I've used their cards for a decade and never had an issue with them.

    24. Re:Alpha by evilviper · · Score: 1
      Have x86 caught in the SpecFP?

      Well, it is pretty hard to wrestle useful information out of the spec.org website... From what I found, it looks like the SpecFP of the fastest Opteron is 75% of the fastest Itanium 2, with the fastest POWER being a bit better still.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    25. Re:Alpha by evilviper · · Score: 1
      A set of SPUs can do the cropping, scaling, static denoise, temporal denoise, gamma adjustment and compression while another set of SPUs can adjust audio volume, dynamic range and compression. This approach would blow the socks off a fast standard core + single SIMD engine.

      The compression is the CPU-intensive process. All the rest in your list uses practically no CPU time on a standard processor. Denoising can waste a lot of cycles (a small fraction compared to compression), but it doesn't have-to, since you can combine it with compression and avoid doing the same number-crunching twice in a row.

      Additionally, video compression doesn't work well in parallel. Threading hurts quality a few percent at a given bitrate, and I can't imagine any way that could be eliminated, to make this very useful.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    26. Re:Alpha by Octorian · · Score: 1

      Though what's even cooler is that this was when IBM came out with the POWER2, which could kick the crap out of a 200MHz Alpha, while only running at 66MHz.

    27. Re:Alpha by TheRaven64 · · Score: 1
      Even ignoring everything else good about the Alpha, the PALcode concept is one that should not be allowed to die. I laugh whenever I look at Xen code. It's a huge pile of hacks designed to make a brain-dead architecture act like a sane one. To implement virtualisation (true virtualisation, not just paravirtualisation) on Alpha all you needed to do was replace the PALcode with an image that added an extra layer of indirection. You could run VMS (ported from VAX) and Windows (ported from x86) on the same platform by implementing a set of privileged instructions that were similar to those on the original platform. You could even implement message passing as an atomic instruction[1] so you didn't need any OS intervention (and therefore context switches) for locking.

      [1] The VMS PALcode image, as I recall, contains a set of instructions for adding and fetching integers from a queue.

      --
      I am TheRaven on Soylent News
    28. Re:Alpha by yorkpaddy · · Score: 1
      - effectively using Registers for argument passing
      When AMD made the x86-64 they only gave 16 registers, this is pretty annoying. They had the chance to rewrite everything, why not give 64 or 128 registers, you aren't bound by legacy? Another thing, everyone says that x86 is now risc micro-ops under the hood. Why doesn't intel or AMD let people program straight to those micro ops, if they wanted the speed advantadge?
      --
      "brxref .k.p ,.by xprt. gbe.p.oycmaycbi yd. cby.nci.bj. ru yd. am.pcjab lgxlcj" don'
    29. Re:Alpha by hughk · · Score: 1

      More of them went over to AMD. This is one of the reasons that they have been doing so well.

      --
      See my journal, I write things there
    30. Re:Alpha by Anonymous Coward · · Score: 0

      Well, IBM invented those "co-processors" around the eighties I believe.
      Their "big-irons" have had them for generations, and that's why they're still it when you need to do real I/O, they have separate processors there just for I/O.

      -D

    31. Re:Alpha by Anonymous Coward · · Score: 0

      By moving to Intel, Apple gains the option to possibly license its OS to other x86 PC clone makers in the future.

      Yes yes, all the press and hoopla says they won't do this. But the choice is available and very doable.

      It's an option that exists if you go x86, and simply does not exist at all if you don't.

    32. Re:Alpha by TheLink · · Score: 1

      They were bound by legacy. It's easier to extend x86 to 16 registers than 32 registers. I believe there were spare unused bits in some x86 instructions that they could use to do 16 registers, I guess they couldn't find enough to do 32 registers efficiently.

      Plus in a talk at a university (stanford?), one of their designers claimed that once you hit 16 or 32 registers you get diminishing returns. Most bang for the buck at 16.

      Also, if you have lots of registers saving and restoring them starts to take more time... The Itanium approach of having tons and tons of registers doesn't appear to have given it that much benefit.

      Why don't let people code in microops? That's because x86 is now a defacto layer of abstraction. Much like high level language vs machine code. You write in x86, if Intel/AMD etc figure faster ways to do x86, you gain without needing to rewrite or recompile your code.

      Also, x86 seems a fair bit more compact than most RISC code. AFAIK, most RISC code is fixed size, whereas common x86 operations tend to be smaller than uncommon ones. You get a fair bit of performance gain from smaller code size. So think of x86 as compressed code with modern x86 cpus decompressing x86 on the fly to RISC, from low bandwidth (mem, 2nd level cache) to high bandwidth - on chip (or trace cache with P4s).

      Lastly the Opterons perform as well as the RISC chips, so 16 registers, x86 legacy etc isn't really such a big disadvantage.

      The opterons are doing it even with a comparable transistor count. Go look at the Itanium transistor count, sure the actual core is small, but how well does it perform in real life without those large caches? I haven't seen any real life tests or benchmarks of Itaniums with small caches, most have effectively _double_ the transistor counts of x86 chips (opteron or P4). For that number of transistors (400 million?) you can have a _dual_ core opteron.

      --
    33. Re:Alpha by ooze · · Score: 1

      Well, Compressing RISC in a proper way isn't that hard. ARM Thumb does a pretty good job of this. Also the TriCore chips do that pretty well. It's even more efficient than ia32 as far as I know.

      POWER doesn't have a compressed instruction set. But it still scales seamlessly from the tiny embedded to the biggest iron with all inbetween. And you can seamlessly and transparently intermix 32bit and 64bit addressing instructions, without having to switch modes or do anything like that. Have 32bit code but a 64 bit processor? No problem running it at the same time without an emulation layer (like you need for amd64, when you want to run ia32 code). Happening all the time on MacOS X with PPC.

      --
      Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
    34. Re:Alpha by ArbitraryConstant · · Score: 1

      "Another thing, everyone says that x86 is now risc micro-ops under the hood. Why doesn't intel or AMD let people program straight to those micro ops, if they wanted the speed advantadge?"

      These wouldn't make much of an ISA, they're quite large and are subject to change with every core revision.

      --
      I rarely criticize things I don't care about.
    35. Re:Alpha by hr+raattgift · · Score: 1

      I wasn't proposing threading or parallizing in the video compression case, I was proposing streaming. This eliminates the overhead of context switching and the continual setup of the SIMD code of each stage of the stream within the PPE program itself. This trade-off involves the use of the Core architecture's mailboxes, which is mostly a SMOP.

      You could think of this as if it were a UNIX pipeline:

      cat video.mp2 | decompress | crop | scale | ... | compress | dd of=video.mp4

      where each process runs on its own processor, and the bandwidth through the pipes is very large.

      Some of the CPUs will block waiting on the compress stage. That happens in reality, both in the heavyweight and lwp/thread models which exist today. However they are blocking/running/unblocking without taking away processor time from the compress stage, and that is likely to be a significant and noticeable improvement in overall workflow throughput.

      Video processing often *is* highly amenable to parallel processing: the coordinating process ships off a discrete chunk of video -- a GOP perhaps, or a chapter -- and gets back a compressed version at some point in the future.

      Finally there is a per-frame parallelization in a streaming approach that can *help* with quality, notably exhaustively searching fullpixel motion estimation in the compression stage is likely to be made quicker by doing different algorithms on different SPUs in parallel, and discarding the lower-quality results returned from them.

      The multi-SPU large model programming model IBM likes to talk about is amenable to that sort of branch-and-prune streaming approach, which is useful in a number of floating-point intensive workflows. Video is one of them, obviously, but not just as the equivalent of GPU-style shader engines. (On the other hand, you could think of it as exactly the equivalent of GPU-style shader engines with output going to a file rather than to a screen -- and in that sense, Cell would be competing with a graphics subsystem that can *compress* to H.264 et al rather than just accelerate the decompression and display of them).

    36. Re:Alpha by ArbitraryConstant · · Score: 1

      x86 isn't explicitly compressed like Thumb, but it still enjoys smaller code sizes than most RISCs.

      It's not ideal, but I think it's fair to say that with a sufficiently large investment AMD and Intel have overcome the disadvantages, at least for laptops/desktops/small servers.

      --
      I rarely criticize things I don't care about.
    37. Re:Alpha by spectre_240sx · · Score: 1

      Wouldn't a decent optimizing compiler be able to do this while providing a layer of abstraction that would let the same code work on both AMD and Intel processors?

    38. Re:Alpha by bored · · Score: 1

      • 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


        Register passing has always been supported, of course passing more than 4 parms was a problem, but not that much of a problem considering research about this pointed out that most C functions had less than 4 parameters. Even so, the x86-64 extended this enough that its really a non issue.


        Modern BIOS's have 32-bit entry points, which are used by all major OS's. This has been true for a long time. This isn't really an x86 issue so much as a platform issue anyway..


        Trust me on this one, the x86 compares very favorably to other high performace CPU's on actual absolute context switch times in major OS's. These numbers are a lot more complicated than just counting the cycles the manual says it takes for the sysenter call (for example TLB flushing if nessisary and associated reloads, etc). A quick google search provides an old example: http://www.ro.feri.uni-mb.si/predst/martin/4_12_20 00/301specs.html. and another http://www.ebsnetinc.com/RTKernel-RISC-real-time-p erformance.php. I've seen some more recent charts and they say similar things. The OS ive worked on had hundreds of lines of code (PPC based and another ARM based) to do the same thing the x86 was doing in just a few heavier instructions and the net result was a wash.



        I'm not sure what in particular your talking about (memory table lookup? hu? sounds like your talking about indexed address modes). The talk about COW and dirty page flushing sounds like don't know about the INVLPG instruction. COW and dirty page flushing are OS functions having single TLB invalidate instrucitons like INVLPG make that as simple as updating the page, followed by TLB invalidate.



    39. Re:Alpha by evilviper · · Score: 1
      cat video.mp2 | decompress | crop | scale | ... | compress | dd of=video.mp4

      where each process runs on its own processor, and the bandwidth through the pipes is very large.

      That's nice and all, but as I said, those use such a trivial percentage of the CPU power, that it wouldn't be worth $10 for a 100% speed-up on non-compression tasks. Most CPU cycles in video playback are wasted on displaying the content, not on the actual decompression. Scaling takes very little. Croping takes almost no CPU time. etc.

      Video processing often *is* highly amenable to parallel processing: the coordinating process ships off a discrete chunk of video -- a GOP perhaps, or a chapter -- and gets back a compressed version at some point in the future.

      If you were to do it in huge chunks (chapters) it could work, but not easily, and not without losses.

      First of all, you'd have to do a first-pass on a single processor with all the motion estimation, scene-change detection, b-frame placement, etc. Then, you can't just cut it up at the I-frames because then the frames at the end of one group can't insert some b-frames which would depend on the I-frame of the next group, which would hurt quality a bit.

      The same is true for I-frame placement. Most codecs dynamically decide where to place them, depending on how close to the specified bitrate it currently is, as well as scene-changes. You'd also risk exceeding your specified I-frame interval, or rather, placing extra I-frames where they aren't really needed.

      You'd also be completely throwing-off ratecontrol, since one chip really won't know what average bitrate has been used by (eg.) the 7 segements before it. Requiring ratecontrol to make each segment of the video come out to exactly the ABR would maintain the appropriate bitrate, but would lead to even worse quality.

      So, basically, you've moving most of the processing burden from the (currently slow) 2nd pass, into the (currently fast) first pass. Since, the first pass can be made very fast by disabling or lowering the strength of some of these computations (the the "turbo" option in Xvid, lavc, etc), I can't see the net speed being much of a gain, and again, you have still lowered quality slightly, this would only work well on very long videos, and you'd be paying a lot for the privlidge.

      It occurs to me that, once you've written software that could manage all of this, you could just send each segment of video to a different machine over the network (and back) instead of to a cell, as delay in this design wouldn't be so important.

      Finally there is a per-frame parallelization in a streaming approach that can *help* with quality, notably exhaustively searching fullpixel motion estimation in the compression stage is likely to be made quicker by doing different algorithms on different SPUs in parallel, and discarding the lower-quality results returned from them.

      Well, that much may work, if the uncompressed frame along with motion vectors and other info can be transfered quickly enough from one chip to several others, run on those chips, and returned all in less than, say 1/100th of a second. However, perhaps a single (second) CPU could already do all that, as could a single ASIC. So, perhaps an advantage, but likely a very small one.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    40. Re:Alpha by hr+raattgift · · Score: 1

      I think (and this is because of your reference to "Xvid, lavc, etc") that we are discussing totally different markets. My point is not that Cell is a good fit for Apple's mass market segments comprising home and casual hobbyist users.

      I am suggesting that the Cell would be good for very high-end Apple customers processing HD "live" in the truck. The sort of people who have teams doing NLEs to allow for instant replays and the like, for full HDTV broadcast.

      Organizations like Molinare for example, not people at home ripping DVDs into CD-sized mpeg4s.

      That particular application would benefit from Cell precisely because the source and destination format bitrates are so high that cropping, scaling, gamma-correction and the like do use noticeable computation, enough to pose the risk of a delivery delay unacceptable to in-the-truck broadcasters' customers.

      Incidentally, the formats being handled are HDV and MPEG2 at various bitrates. MPEG2 as a source format is laid out in GOPs; MPEG2 as a destination format has predictable (even settable) GOP layouts and settable data rates. Parallelization by GOP is precisely what happens in this type of application, whether it's done in a multiprocessor/multisystem rack or using multichip hardware compression engines.

      However, in Moliere's workflow and any other Apple-using software-only setup, parallelization is mostly to access the Velocity Engines for floating point performance, and the overhead for this is high (network driver code on both machines, time on network, synchronization code) and for applications which parallelize over 4 dual core G5 XServes for access to their Velocity Engines, the Cell would eliminate the first of these two overheads entirely, and dramatically simplify the last.

      When the target is HD and SD broadcast you benefit from parallel compression as I outlined. Yes, you can also benefit from this for delivery to other media (DVD, HD-DVD/Blu-Ray eventually, or even a video iPod compatible mpeg4) however most high-end customers know that offline formats don't need massive parallelization in the final preparation, just as you do.

      In short, the mass market does less-time-sensitive workflows that would like to reduce (but are tolerant of) slow (or even no) NLE, and can wait hours for delivery of edited source material to non-broadcast formats.

      Higher end customers want quicker NLE because they are paying professional editors and have budgets for expensive equipment. Those that are working on recorded content to be delivered at a particular time (film release date, TV show air date) are the customers that Cell would attract.

      Moreover, video is not the only obvious high-end application as far as Apple's serious pro customers go -- almost every application listed in Apple's Pro (UK) page is heavily floating-point dependent and uses SIMD parallelization already. Several would benefit from the massive floating point performance available with the Cell architecture -- essentially the Cell would bring a greater than 4x increase in available Velocity Engine power per system compared to systems using G5s.

      However, it's not clear that Cell would scale as well as denser and denser G5 systems for the ultra high end applications because the control logic for massive parallelization (especially just sourcing and sinking the data) could begin to push at the PPEs limitations compared to those of the G5's PPC core, or might wind up being called upon to do much more non-floating-point computation at some point in the future. Therefore, the larger cluster applications listed at Apple's (US) Pro page might not be suitable for the Cell. However, as with the UK page, many are.

      So, there is a clear and profitable market segment that would benefit from the Cell enough to buy new Cell-based Macs. Whether that segment could pay for the software and hardware d

    41. Re:Alpha by evilviper · · Score: 1
      I think (and this is because of your reference to "Xvid, lavc, etc") that we are discussing totally different markets. My point is not that Cell is a good fit for Apple's mass market segments comprising home and casual hobbyist users.

      The reference to Xvid and lavc was only about first-pass encoding speed-ups. lavc, in particular, has codecs for MPEG-1/2/4, WMV1/2, h.263(p), snow, svq1, etc., and "turbo" can speed-up the first pass for all of those, so it's not just useful for home users ripping DVDs.

      I am suggesting that the Cell would be good for very high-end Apple customers processing HD "live" in the truck.

      Cutting up videos into "chapters" and encoding each on a different processor, as you previously suggested, would not possibly work for "live" encoding. If you try threading for realtime encoding, you have the same drawbacks as I've listed before. And once again, the only intensive part of the process is video encoding, which can be done quite easily on a single purpose-built ASIC, and doesn't need multiple cell processors. In other words, I don't see how this could be even slightly useful for "live" work.

      [...] the source and destination format bitrates are so high that cropping, scaling, gamma-correction and the like do use noticeable computation,

      Still, no. All it requires is a memcpy, and modern systems have such high memory throughput that it's a non-issue. If you wanted to, you could re-write the crop/gamma/scale/etc. filters so that all the operations could be performed in the same spot in memory, eliminating the memcpy from one filter to the next.

      MPEG2 as a source format is laid out in GOPs;

      Yes.

      MPEG2 as a destination format has predictable (even settable) GOP layouts and settable data rates.

      No. Not without sacrificing a lot of quality to do so. Sure, you can always have a strict GOP setting, and CBR encoding, but you will spent a lot more bits on much worse quality, as I've already said.

      Parallelization by GOP is precisely what happens in this type of application,

      Which is likely part of the reason why standard software encoding beats the crap out of a solution like this at the same bitrates. The more inflexible, the worse the quality.

      You are saying that cell might do slightly better than the current crop of vastly ineffecient methods of video compression. Well, you're welcome to it. However, computers have long since surpassed both methods, and it's surely only going to be a short-time before broadcasters come to realize this.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    42. Re:Alpha by hr+raattgift · · Score: 1

      Cutting up videos into "chapters" and encoding each on a different processor, as you previously suggested, would not possibly work for "live" encoding

      Precisely, thus the multi-SPU pipeline approach.

      This type of application is written as a pipeline anyway, QuickTime et al simply favour that programming model, and coincidentally benefit from spreading pipeline stages across multiple processors on a system that has them.

      The EID is much much faster than main memory, and the Cell's internal mailboxes are much quicker synchronizers than any multiprocessor approach.

      So, for pipelines dominated by floating point work, Cell is a winner.

      can be done quite easily on a single purpose-built ASIC, and doesn't need multiple cell processors

      Single-Cell systems would be cheaper than extant hardware solutions (single G5 Mac + Enigma or Altair for example). Sure, an ASIC or FPGA approach is thinkable, but not with the combination of cost and flexibility that a Cell system could. For that matter, a quad G5 system often outperforms extant hardware approaches, even though it has less than half the vector processors of a single Cell.

      Still, no. All it requires is a memcpy

      Huh?

      Computation depends on the number of pixels. More pixels, more computation. More pixels in a given unit of time, more computation in that unit of time. Pixels over time is bandwidth or, alternatively, bitrate.

      HD is lots of pixels per second and a typical source is lots of bits per pixel... mutating all the pixels in a frame is not computationallly free, and if you have timing requirements, this is important.

      I don't see where memcpy cost comes into it. The dominant cost is e.g. the gamma function against every 24 bpp datum, or a 2D-FIR scale across every frame or field.

      Memory can be a bottleneck, but that's feeding data into the floating-point processors... The idea is to avoid constantly blowing caches by either:

      [possibly keeping code in cache, probably thrashing field data]
      - process field through mutation algorithm A (run to completion)
      - process field through mutation algorithm B (rtc)
      - process field through mutation algorithm C (rtc)
      - next field

      [possibly thrashing code, probably not thrashing field data]
      - process pixel through mutation algorithm A
      - process pixel through mutation algorithm B
      - process pixel through mutation algorithm C
      - next pixel

      It's likely you have to have some of the first approach if you take the second; some operations are going to work on full fields or frames.

      A pipeline lets you do this if you have multiple processing units:

      [on processor 1]
      - read pixel from source
      - process pixel through mutation algorithm A
      - write pixel to proc 2

      [on processor 2]
      - read pixels from proc 1, assemble field
      - process field through mutation algorithm B (rtc)
      - write pixels to proc 3

      [on processor 3]
      - read pixels from proc 2
      - process field through mutation algorithm C
      - write pixels ...

      The Cell's SPUs are well-suited to this type of small program, and tends to favour small rtc algorithms.

      You can do this with multiple standard processors too, but the "write to proc N+1" "read from proc N" pairs are likely to be much slower than SPU->SPU communication which benefits from the extremely fast EID.

      Finally, for completeness, you can do it with one standard processor as well, although then overhead of what is ultimately a threaded/distributed functional programming style will be a performance drawback compared to a non-threaded monolithic style.

      Sure, you can always have a strict GOP setting, and CBR encoding, but you will spent a lot more bits on much worse quality, as I've already said

      Today's broadcast media (ATSC) are typically CBR anyway...

  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.

    1. Re:tisk tisk by Eightyford · · Score: 1

      I'm sure the shareholders would love that!

    2. Re:tisk tisk by Anonymous Coward · · Score: 0

      I can save them $9B. Instead of spending $10B (more) on Itanium give me $1B. They will get exactly as much out of this billion as the $10B they are planning to waste.

      The stockholders will be happy to save all that dough, the future of Itanium will be unchanged, and I'll be very happy indeed!

    3. Re:tisk tisk by Anonymous Coward · · Score: 0

      Is it just Me, or is that a priorities troll? (See Wikipedia's article on Slashdot trolling phenomena.)

    4. Re:tisk tisk by Anonymous Coward · · Score: 0

      Pfft. This is all part of their contribution to charity. The excess heat generated by Itanium plus the global warming boost from the extra electrity they suck down will help the poor stay warm the world over.

    5. Re:tisk tisk by AFairlyNormalPerson · · Score: 1

      But what if they fed the chips to the starving kids?

    6. Re:tisk tisk by Just+Some+Guy · · Score: 1
      they should donate to help feed some starving children not starving platforms.

      Sounds to me like they're donating $10B to the children of chip designers, plant architects, and construction workers, so I guess you got your wish.

      --
      Dewey, what part of this looks like authorities should be involved?
  4. Why? by Anonymous Coward · · Score: 0

    Am I the only one who doesn't see the point in this?

    1. 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
    2. Re:Why? by Firehed · · Score: 1
      Indeed. You think they'd be smart enough to spend that $10B on R&D and marketing for their desktop chips, and just give the thing up with servers. I'm sure with that chunk of funding arriving overnight, they could whip together an 8-core desktop/laptop monstrosity by Q3'06. And as nice as my X2 is, I'd convert for some eight-way lovin' (oh, that's just so wrong).

      Or just give everyone in the US $40. Even if they make everyone promise they won't use it towards their new AMD system.

      --
      How are sites slashdotted when nobody reads TFAs?
    3. Re:Why? by Anonymous Coward · · Score: 1, Insightful

      "non 32bit backwards "
      Huh?, IA64 is a new architecture.
      It is good that the x86 hardware unit is out of the die now.
      It has hampered the design and speed of the CPU.

    4. Re:Why? by Blackhalo · · Score: 1

      The problem for Intel and Itainum is that there is too large of an X86 installed base of applications that makes migrating to Itanium cost prohibitive. Even on the server side, so much of the software out there that has already been developed, mostly in-house, and the CTO's and what not who would have to migrate their applications to the new architecture look at the additional development costs and say, "No thanks."

      Certianly there is still a role for Itanium for specialized newly developed projects, but a whole scale migration will not happen in my opinion for the next ten years.

      --
      "There is nothing to do it. But to do it." -Floyd Pepper
  5. 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/

  6. 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 ChrisGilliard · · Score: 1

      Last time I checked hyperthreading wasn't enabled on the Intel dual core chips. Even if it is enabled on the latest Intel chip, that is only 4 threads total. That's nowhere near the 32 threads in the UltraSparc T1. Sun's next generation is Rock which will have 64 threads in a single chip! By the time Intel gets to 8 threads per chip, Sun will be at 64.

      --
      No Sigs!
    4. Re:Itanium vs. Ultrasparc T1 by jayslambast · · Score: 1

      Well, maybe to answer your question: If you have a heavy cart to need to be moved do you?: A) Use a hurd of chickens to pull it (Sun T1) B) Use a couple of oxen (Itanium) I'm thinking B, but those chicken are 'eco friendly' so maybe some greenpeace people will help pull the cart with them.

    5. 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+."

    6. Re:Itanium vs. Ultrasparc T1 by ChrisGilliard · · Score: 1

      While a T1 thread is a little slower than an Itanium thread, I would hardly say that it's a chicken compared to an ox. But to go with this, the T1 runs at 1 Ghz while the latest Intel chips run between 3 and 4 gHz. I know you cannot extrapolate performance directly from frequency, but it does give some idea of how fast these threads run. So, say your Intel chip is about 4 times faster. Since there are only two threads running, your performance is 2 X 4 = 8 generic performance units. For the UltraSparc, you've got 32 threads running at 1 generic performance units. That means 32 generic performance units. So, you get WAY more throughput and use less power as you've pointed out. Now, some people have argued that it's better to have a single (or a few) blazing fast cores. Sun has taken the view that it's better to have a LOT of somewhat fast cores. Since these high-end chips are mostly used for servers that handle many many users, it's clearly better to have many somewhat fast cores that use less power and on a performance basis are MUCH cheaper.

      --
      No Sigs!
    7. Re:Itanium vs. Ultrasparc T1 by Anonymous Coward · · Score: 0

      The T1 has terrible FP performance and middling integer performance. It's basically an I/O processor. If that's what you need, then you don't want an Itanium 2. If that isn't what you need, you don't want a T1. Can you imagine doing CFD computations on the T1? Hah. That would be something.

    8. Re:Itanium vs. Ultrasparc T1 by Anonymous Coward · · Score: 0

      Does anyone out there actually know how the latest power 5 chips compare to itanic/T1/opteron? I understand the price of > 4 processor systems becomes more competitive.

    9. 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!
    10. Re:Itanium vs. Ultrasparc T1 by Anonymous Coward · · Score: 0

      While the T1 is perfect for a web server, there are lots of database tasks which he isn't good at. For any simple query, a T1 would be perfect. However, keep in mind that the T1 has for all the 32 threads he can run a SINGLE FPU. A T1 is good to make many simple things, not few complex things.

    11. Re:Itanium vs. Ultrasparc T1 by Ewan · · Score: 1

      Your logic is based around the concept that every task is highly parallel - they're simply not.

      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.

      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.

      On 90% or more of workloads out there, a 32 thread core would have about 28 cores sat idle and 4 cores working flat out.

    12. Re:Itanium vs. Ultrasparc T1 by gbobeck · · Score: 1
      Dual Core = 4 threads
      Hyperthreading = 8 threads
      Quad Processors = 32 threads

      Ok, I know there are a few /.'ers out there that are thinking the following...

      My Sheets = 500 threads (per inch)
      --
      Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
    13. Re:Itanium vs. Ultrasparc T1 by masklinn · · Score: 1

      Last time I checked hyperthreading wasn't enabled on the Intel dual core chips.

      I'd strongly suggest you to reflect upon the following words: "Intel Pentium Extreme Edition 840 'Smithfield core'"

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    14. 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)

    15. 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.
    16. Re:Itanium vs. Ultrasparc T1 by Anonymous Coward · · Score: 1, Interesting

      Niagara, aka UltraSPARC T1, actually has 8 very simple 64-bit integer execution units. One has an FPU. At any one time, only 8 threads are actually being executed.

      Where the performance comes from is how it cunningly hides memory latency. Niagara has 4 on-board memory controllers (c.f. 1 on the AMD Opteron/Athlon 64 and zero on the intel Pentium which has it on the motherboard's northbridge.)

      Those 4 memory controllers are connected to high-bandwidth memory busses. On a conventional CPU, as much of 75% of the available clock cycles are spent idling wating for data to be fetched from memory.

      Each Niagara core can hold 4 thread contexts i.e. a set of registers and other relevant stuff. It can switch between contexts instantly. It uses this ability to switch to a new thread when the current thread stalls waiting for a memory access. It tells the memory controller to fetch the data for the stalled thread and concurrently begins executing the next thread, and so on.

      It's been a while since I was fired from Sun, but IIRC they reckon they can hide 98-99% of the memory latency on highly multithreaded (i.e. Java) workloads. Ideal for running Sun's own software stack.

      It means that the processor has a relatively low transistor count (more to spend on cache), can run at a relatively low clock frequency (~1GHz), will be cheap to make and will consume very little power compared to Xeon and especially itanic.

      A year after Sun announced Niagara, intel did a huge public U-turn, admitting that the Pentium IV design was a dead-end and that they'd be moving to multi-core processors. Still no sign of on-board memory controllers, NUMA etc...

      And itanic is a shipwreck. I bet Sun, IBM and AMD are wetting themselves laughing at intel and HP throwing away billions of dollars on the commercial suicide that is the itanic.

    17. Re:Itanium vs. Ultrasparc T1 by Svartalf · · Score: 1

      Of course, Quad CPUs in the case of an UltraSparc T1 translates into an even bigger disparity.

      Everyone needs to face facts here- Itanium's an expensive flop akin to the iAPX432 CPU also from Intel. Unlike the i432, Intel didn't have the good sense to realize that while it looked good on paper, it didn't look so good in silicon and as such, they pushed the Itanium forward when it should have been euthanized earlier on. It performs decently in native mode, but not as well as comparably priced CPUs from AMD, Sun, and IBM. It does support the legacy sofware in a sort of emulation mode, but slower than any comparable machine from AMD.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    18. Re:Itanium vs. Ultrasparc T1 by LWATCDR · · Score: 1

      I have no less than 32 processes running on my workstation. I doubt that 90% of systems have less. I know that our small database server often has 50 client threads running at any one time.
      A Spark T1 is a very useful system for many tasks. Does it go head to head with the Itanium? Well if you try to us an Itanium for typical server tasks like SQL or web I would bet that T1 will beat it soundly. If you are using it for running a simulation or rendering? Itanium would probably beat the T1.
      The Power and Ultrasparc really seems to handle both kind of tasks very well. I would love to see how a Power5 does vs an Itanium for FPU and how it does vs a T1 for SQL.

      What everyone is glossing over is the real problem with the Itanium. Compiler technolgy did deliver the speed that the Itanium promised.
      Just like Intel's last disaster the 80860 http://www.sasktelwebsite.net/jbayko/cpu5.html#Sec 5Part3. The 80860 was supposed to be very fast and was on carefuly hand opmized code. The performace using standard compiled code was only so so. The Itanium was pretty much in the same boat. It was fast for very specific tasks but in general it was slow, hot, and expensive.
      As a rule it looks like general purpose CPUs that require very special compilers don't work out well.
      I find it interesting that with the exception of the x86 and the 8051 Intel has had one disaster after the other. Even the 8080 line was eclipsed by the Z-80 much as the X86 is being beat by the AMD64 line.
      If you take a look at the list of the "next big things" from Intel that have flopped it is pretty long.
      The 432, Rambus, 80860, and the Itanium and yes the Itanium is currently a failure. Has it made money? Is it growing in market share? I think not.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    19. Re:Itanium vs. Ultrasparc T1 by ChrisGilliard · · Score: 1

      Your logic is based around the concept that every task is highly parallel

      No it's not. I was talking about webservers/app servers. In a webserver, it makes littler difference if one page is served out faster, but you want to have a lot of throughput. The T1 has much better total throughput.

      --
      No Sigs!
    20. Re:Itanium vs. Ultrasparc T1 by ChrisGilliard · · Score: 1

      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.

      Your refering to the Sun Fire T1 server. This is a low-end system because it has a single chip. They will be releasing high-end systems based on the UltraSparc T1 that have multiple chips. The Ultra Sparc T1 is most definitly NOT considered a low end chip. It's designed compete with the IBM Power 5 really.

      --
      No Sigs!
    21. Re:Itanium vs. Ultrasparc T1 by ArbitraryConstant · · Score: 1

      "Well, maybe to answer your question: If you have a heavy cart to need to be moved do you?: A) Use a hurd of chickens to pull it (Sun T1) B) Use a couple of oxen (Itanium) I'm thinking B, but those chicken are 'eco friendly' so maybe some greenpeace people will help pull the cart with them."

      OTOH, if you've got thousands of small carts, it makes sense to use chickens instead of oxen.

      Many systems benefit more from good single-thread performance. For example, Niagara wouldn't make a good desktop chip. But the servers it's designed for deal with thousands of requests concurrently.

      --
      I rarely criticize things I don't care about.
    22. Re:Itanium vs. Ultrasparc T1 by Bing+Tsher+E · · Score: 1

      Sounds like a new soft drink for snowboarders.

    23. Re:Itanium vs. Ultrasparc T1 by Bing+Tsher+E · · Score: 1

      It does support the legacy sofware in a sort of emulation mode, but slower than any comparable machine from AMD.

      People said the same thing about the Pentium Pro. It didn't run 16 bit software as fast as a regular Pentium.

      Nobody cared, anything important was updated to be native 32 bits.

      Really, all AMD has going for it in many regards is 'legacy.' It used to be that people here on Slashdot respected legacy, but didn't see legacy compatability as the end-all issue.

    24. Re:Itanium vs. Ultrasparc T1 by masklinn · · Score: 1

      Well, it's expensive stuff for tools & dummies, so i guess it qualifies.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  7. They can't not do this by Anonymous Coward · · Score: 1, Funny

    I saw a documentary on TV a while ago about the impact that Moore's Law has had on the world economy.

    Essentially it stated that:

    . The big economic powerhouses of the world are based largely on IT
    . A key driver for the developemnt of IT is the continual improvement in computer power (and corresponding drop in price)
    . When Moore's Law hits the basic physics of silicon, and they can't make any more faster chips, then this economic driver stops

    If Intel and so on don't keep on pushing Itamiums then unless AMD can keep ahead we are all in trouble

    1. Re:They can't not do this by Anonymous Coward · · Score: 0

      Not really, once silicon has reached its limits they will find something new to make chips out of. To say that is like whoever it was in the early 1900's who suggested closing the Patent office because "everything that could possibly be invented already has been." Go figure.

      Didnt I read in wired a couple years back about artificial diamonds and how they could replace silicon in chips?

    2. Re:They can't not do this by ChrisGilliard · · Score: 1

      If you believe Moore's Law is the end of computing performance increases, yes this would pose a problem. Although, according to the roadmaps for the major chip manufacturers it's not going to happen for more than 10 years. But since Silicon is not the first substrate that we've continously increased computing performance with, I don't think it will be the last. Before we were improving performance with Silicon, we were using Vaccuum tubes. Before that, relays. If we use very conservative estimates for the power of Carbon Nanotubes, which are being researched extensively at many universities, we can extend the improvements in computing power out until 2060. I haven't even mentioned quantum computing.

      --
      No Sigs!
    3. Re:They can't not do this by Anonymous Coward · · Score: 0

      Its gonna be really interesting to have computers with chips running at 400 degrees F. Thats gonna be an interesting challenge for case makers.

  8. 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!
    2. Re:Here is the problem by thsths · · Score: 1

      > 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).

      I don't know. The Itanium might not want to compete with the Opteron, but the Opteron is certainly competing with the Sparc architecture, and that might mean there is less of a reason to go down the increasingly uncertain Itanium path.

      As for PowerPC, I think IBM is happy with niche applications for embedded systems and scientific computing. Itanium might be a contender for the scientific computing, but even there the Opteron is scoring with its low price tag.

    3. Re:Here is the problem by Bert64 · · Score: 1

      Linux and BSD also run on Sparc...
      Microsoft have recently severely cut back their support for itanium.

      As for where you buy the server, sure you can buy an itanium box from many vendors, but the cpu will only come from intel. With sparc the processor and/or the entire system can come from Fujitsu or Sun, you actually have _MORE_ choice if you go with Sparc...

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    4. Re:Here is the problem by Animixer · · Score: 1

      >>while the only OS that currently runs on Sparc is Solaris.

      Tell that to my ultra-60 running gentoo and the ultra-1 running netbsd. They might disagree.

      --
      man tunefs | grep fish
    5. Re:Here is the problem by PCM2 · · Score: 1
      Linux and BSD also run on Sparc...
      With support from any enterprise-class vendor? To my knowledge, neither Red Hat nor Novell ships a distribution for Sparc. Both support IA-64. I don't know if any Linux distribution will run on UltraSparc IV -- maybe you know better. But I kind of doubt any company is going to sink significant dollars into a high-end UltraSparc IV setup for mission-critical computing and then run an unsupported version of Debian on it. It just doesn't make any sense.
      As for where you buy the server, sure you can buy an itanium box from many vendors, but the cpu will only come from intel. With sparc the processor and/or the entire system can come from Fujitsu or Sun, you actually have _MORE_ choice if you go with Sparc...
      OK, so Sun and Fujitsu sell Sparc systems. And that's more choice than Bull, Fujitsu, Fujitsu-Siemens, Hitachi, HP, NEC, SGI, and Unisys? Your math is funny.

      But hey, you don't have to believe me. I'm just telling you guys what the Itanium Solutions Alliance is selling. If you guys never buy an Itanium system as long as you live, it's no skin off my nose.

      --
      Breakfast served all day!
    6. Re:Here is the problem by Bert64 · · Score: 1

      But regardless of which itanium vendor you use, the most important component (the processor) and most likely the support chipset too, come from a single source (intel).
      Sun and fujitsu on the other hand both produce their own complete systems.

      There also used to be a number of other companies producing sparc processors, like ross/bridgepoint, cypres, hitachi, bull etc...

      So with itanium you still have intel as a single point of failure, which is not the case with sparc or x86, or even PPC.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  9. 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.

  10. 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?

    1. Re:The point is? by Anonymous Coward · · Score: 0

      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?

      There is no point. Your list of 'real world production applications' IS the source of your hack/patches and headaches. And it's stupid to run this glorified PC crap on 'big iron'. You can thank bill gates' greed and the IT industry that has blindly allowed him to get everything he wants by building out this huge windows-centric intrastructure at corporations everywhere, big and small. And I have seen the hacks and patches firsthand.

      What few are mentioning here (and this makes me less than impressed with this collection of posters), is that you can run OpenVMS, Hp-UX, and Linux on these boxes, and THAT's the point.

  11. Itanium == Xbox by Anonymous Coward · · Score: 0

    The similarity of the two marketplace failures is amazing.

  12. AMD64 by Shawn+is+an+Asshole · · Score: 1

    Are there any advantages to using the Itanium over an Opteron or Athlon 64?

    --
    "It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
    1. Re:AMD64 by Anonymous Coward · · Score: 0

      if you want perfromance you get to trow your legacy code away, a great oportunety to sack all those loyal hard working middel aged expensive programers who held your busines afloat for all those years.

      think of the savings!

    2. Re:AMD64 by linguae · · Score: 1

      Well, you won't have to worry about being cold in the winter....

    3. Re:AMD64 by corngrower · · Score: 1

      For certain few people, yes. It's faster, but considerably more costly (at present). It's great for people doing advanced research on compiler technology.

    4. Re:AMD64 by Anonymous Coward · · Score: 0

      Short answer: no. Long answer: uh, no.

    5. 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
    6. 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.

    7. Re:AMD64 by wakim1618 · · Score: 1

      Previous costs are SUNK costs. The correct line of thinking would be asking something like whether $10B can result in an increase of $10B in revenue over that period - then do the adjustments for interest costs and opportunity costs.

    8. Re:AMD64 by Anonymous Coward · · Score: 0

      You're about as likely to get an unbiased answer here to that question as you would be if you were to ask "What's better, Linux or Windows?"

    9. Re:AMD64 by Anonymous Coward · · Score: 0

      performance

    10. 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...
    11. Re:AMD64 by UlfJack · · Score: 1

      Look at google. They need so much computing power, it's cheaper for them to use a datacenter with lots of them and just replace the _whole_ computer when it breaks. They are not going to buy Itanium. And I'm guessing the same holds for other big companies (think amazon, ebay). Processors are exactly not like cars.

    12. Re:AMD64 by Anonymous Coward · · Score: 0

      Comparing cars and processors is not quite a good comparison. Especially when talking about BMWs. I've found two types of clever engineers. One is the engineer that is clever for finding a simple solution that gets the job done. The other type is clever for getting to work a complicated solution that has many interacting components. BMW engineers are definitely the latter. I like to use the example of brake pad sensors. Virtually everyone in the world uses a metal tab that makes noise when the brakes are low. Simple and effective. BMW (and other German cars) have electrically wired sensors that must be replaced separately and in addition to the brake pad. Complicated and expensive.

      I see AMD as the clever engineers for their simplicity. I see Intel as the clever engineers for making a really complex system work. (Not that AMD64 is simple but it is simple enough to get the job done.)

    13. Re:AMD64 by Stan+Vassilev · · Score: 1

      "Itanic... Itanic... Itanic."

      Flashnews: calling it "Itanic" just become a bit lamer.

    14. Re:AMD64 by Anonymous Coward · · Score: 0

      AMD can continue their push to dominate servers, workstations and desktops.

      With what? The K8? The thing I find amusing about the parent is that he asks if there any advantages to using an Itanium over an Opteron or Athlon 64, as if the latter two were somehow different. The short and useless answer, FWIW, is "yes, there are" but more interesting is that nobody seems the slightest bit worried that AMD haven't released a new processor core for 2 years now.

      Anyone want to take any stabs at when we might see a new core from AMD?

    15. Re:AMD64 by somersault · · Score: 1

      "crappy C" huh? What's better than C? And I assume by C you include C++

      *wonders if you are suggesting Java is better*

      *dies*

      --
      which is totally what she said
    16. Re:AMD64 by Anonymous Coward · · Score: 0

      Google can very easy throw a system that stopped working - and they even can throw away systems that they suspect are going bad
        Too bad that financial data can be destroyed by a computer that is producing wrong results

    17. Re:AMD64 by demachina · · Score: 1

      The core AMD has works very well for the markets they are targeting. It is very expensive and risky to develop all new core these days. If you have one works there is a school of thought you get more mileage out of refining it than throwing it away and starting over. Some bleeding edge customers want all new things and are willing to put up with defects and steep costs as the manufacture tries to recoup the sunk cost.

      Most customers want something that is reliable, affordable, low power and cool. Churning out bleeding edge all new cores every year runs counter to what most people want, in particular its expensive.

      AMD maybe needs a new core to go head to head with Centrino in laptops, or at least refine and better market Turino. They need a better strategy to target phones and settops. They don't need to design an all new core just to satisfy the bleeding edge types. The all new cores in Itanium are slowly destroying Intel in the desktop and server market.

      --
      @de_machina
    18. Re:AMD64 by demachina · · Score: 1

      You seem to think like a Wall Street broker. As long as staggering losses were written off last quarter its like it never happened. Sure, if they invest a few billion more in this dog maybe they will turn it around and make a profit in the future.

      But sunk costs indicate are still vast sums of money the company has spent on something that will probably never turn a profit, and they will probably never recoup what they've invested in it or are about to invest in it. Even Intel isn't a bottomless pool of money. Money they've squandered on Itanium is money they don't have for R&D in areas that will reap benefits, its money they don't have to pay dividends, its money they don't have in the bank. If you keep pouring vast amounts of money in to products that will never turn a profit you are either bleeding successful products white to make up for it or you will eventually end in bankruptcy.

      --
      @de_machina
    19. Re:AMD64 by wakim1618 · · Score: 1

      You pointed out a number of factors that should affect a good business decision. They are all forms of opportunity costs. Putting scarce R&D workers into Itanium means fewer workers available for R&D in other areas. This does not contradict the fact that previous costs are sunk. Consider a more mundane example. Your car needs repair. Whether you repair it depends on a number of factors. However even if it has a long history of repairs, it MAY be the case that you repair it once more because it is cheaper than buying another car. I am not saying whether the Intel decision is correct. It is a comment on the line of reasoning on whether Intel's marketing decision was a good business decision. You may have wished you bought a toyota but it is too bad you bought a ford suv 3 years ago.

    20. Re:AMD64 by be-fan · · Score: 1

      What's better than C? Lot's of things: ML, Dylan, Python, Lisp, Scheme, Haskell, Ruby, Objective-C, Smalltalk, the list goes on. After programming in C++ for many years, and now getting to work on Lisp code, its obviously clear to me which one I prefer to code in. But my point isn't to tell people they should be using Lisp. My point is that if you're into advanced compiler research, its kind of pointless to spend your effort getting C code to run as fast on a VLIW as it does on a RISC. It doesn't advance the state of the art any, it just allows you to use a crappier processor to get the same sort of performance you do now. Working on high-level languages, on the other hand, advances the state of the art. It makes it possible to use high-level languages where previously low-level ones would've been used for performance reasons. More generally, it goes back to the point that processors are cheaper than programmers. Developing advanced compiler technology to make it possible to get away with a cheaper processor, instead of developing advanced compiler technology to make it possible to get away with using less programmer time, well, it seems backwards to me.

      --
      A deep unwavering belief is a sure sign you're missing something...
    21. Re:AMD64 by questionlp · · Score: 1

      For those who need to have large flat or single system image memory requirements, the Itanium can handle up to 50-bits of physical memory addressing and 64-bit of virtual addressing [1] where the Opteron can address 40-bits of physical memory addressing and 48-bit of virtual addressing.

      Right now, the Opteron can scale up to 8 sockets using HyperTransport (at least until the Horus chipset becomes available) while the Itanium can scale into massive number of sockets (which is more of a function of chipset rather than processor).

      [1]: Page 9: http://download.intel.com/design/Itanium2/datashts /25094504.pdf

    22. Re:AMD64 by TheLink · · Score: 1

      It'd be nice if perl, python, ruby etc can run a lot faster than now. I know some work has been done with python. But just hope things advance at a faster rate...

      --
    23. Re:AMD64 by be-fan · · Score: 1

      The primary issue with Per, Python, and Ruby is that they use interpreters, instead of native-code compilers. Smalltalk and Lisp usually use native compilers, which speeds things up quite a bit (between 50% and 100% the speed of C code). However, there is still research for these languages, namely in allowing the compiler to better optimize code written in a high-level style.

      --
      A deep unwavering belief is a sure sign you're missing something...
    24. Re:AMD64 by TheLink · · Score: 1

      "The primary issue with Per, Python, and Ruby is that they use interpreters, instead of native-code compilers"

      Perl compiles to bytecode. Python also has Psyco which is a "specializing compiler". Ruby is slightly different.

      The Pysco bunch appear to be working towards making "High-level languages are faster than low-level ones!" true. Which I thought may be of interest to you.

      --
    25. Re:AMD64 by corngrower · · Score: 1
      That bit about it being great for compiler researchers was a bit of sarcasm. Meaning, the performance of the the itanium isn't all it was hyped up to be because the compilers aren't able to find enough parallelism in the code to keep all six instruction pipelines busy.

      Actually, it may be easier develop more efficient compilers(for the itanium) for the higher level languages than it would be for 'C'. Might be, I don't develop compilers.

      It was hoped, that compilers could take a 'big picture' view of what the program was doing and then compile efficient code based on a global perspective. At any time, the processor has only a limited scope of what's going on and would not be able to do as good a job in instruction scheduling.

    26. Re:AMD64 by be-fan · · Score: 1

      Actually, it may be easier develop more efficient compilers(for the itanium) for the higher level languages than it would be for 'C'. Might be, I don't develop compilers.

      With Itanium, you're stuck writing complex code generators just to get the relative performance of the Itanium up to what simple code generators can achieve on other processors. The effort spent on the code generator represents a lot of development effort that could be focused on optimizing higher level constructs instead.

      --
      A deep unwavering belief is a sure sign you're missing something...
  13. Stock Tip: Short INTC and HPQ now by Anonymous Coward · · Score: 0

    This appears to be an utter waste of capital (to the tune of $10 Billion) in a feeble attempt to rescue something from nothing. Yes, the Itanium costs are sunk costs, but there's absolutely no way that any of the companies involved will see any resonable ROI on this route.

    Itanium missed its window of opportunity--it's time to move on.

  14. 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!
    1. Re:Intel just removed 32bit hardware support by Anonymous Coward · · Score: 0

      No. That has already been developed since 2001.

    2. Re:Intel just removed 32bit hardware support by javaxman · · Score: 1
      Anyone want to tie this into their $10 billion push?

      Yea, this guy does. That cash will help give the platform the backing it needs, but with more focus, i.e. it's not some consumer-box chip, it's a real, big iron server-only chip. It'll heat up a room, but it'll get any single-threaded job done 30% faster than anything else. It's competition is Sparc and the Power5, not AMD and Xenon. It'll get less bad press from the average-use crowd trying to use it for things it's not designed to do.

      Maybe some of that cash will be spent on implementing a great software emulation scheme for x86, but I'm guessing even more will go to porting software to be 64-bit and covering other R&D. Just guessing, of course.

  15. 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)
  16. Ah, capitalism. by Paperweight · · Score: 1

    Competition In Action!

    "This is a $140 billion opportunity on hardware. It's dwarfed by the opportunity in software and services on top of that," Kilroy said. "There's a reason there's $10 billion of investment in play."

    And 1400% profit, too! Nice.

    1. Re:Ah, capitalism. by TopSpin · · Score: 1

      This is a $140 billion opportunity on hardware.

      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?

      Itanium, a high-end processor, was once expected to sweep the server world. But because of delays, initial performance issues and software incompatibilities...

      No mention of cost. Itanium is expensive. This fact obviates most of the server market that is well served by cheaper platforms. Why pay a premium for performance you don't need? Dollar for dollar, Itanium is slow. Until that problem is fixed they are throwing good money after bad. The market that was once willing to fund large margins for business hardware is gone.

      In business computing performance is fungible. Today, I can adequately run most business software on Intel x86, Itanium, SPARC, PA-RISC, Opteron and POWER. It's understood my servers must be production grade equipment. Once that is assured the remaining question is simple; who provides the most performance per dollar? Itanium, as far as I can tell, has never even attempted to compete in that space.

      There certainly are customers that need as much performance as possible from every core, damn the cost. This, however, is merely a niche. For typical business applications cost is an imperative with every purchase. Until Itanium is cost effective relative to the competition it will remain in a niche. A small, dwindling niche.

      BTW, I think Sun may have a winner on its hands with the UltraSPARC T1. 8 cores with 8GiB of RAM in 2U for $13k. That could handle a lot of SIP streams with Asterisk. Anyone tried this?

      --
      Lurking at the bottom of the gravity well, getting old
    2. 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
    3. Re:Ah, capitalism. by Anonymous Coward · · Score: 0

      The bit about operating on 100 registers simultaneously is not true. Cerainly Itanium cannot complete 100 operations in a single cycle; the real number might be 4 or 8 if the instruction bundles are completely full, which usually isn't the case.

    4. Re:Ah, capitalism. by Anonymous Coward · · Score: 0

      "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."

      When I hear "pretty specialized" I think DSP, or one of those gate array stuff.

      If that's all the Itanium is good at, it should be buried. The POWER5 is a much better processor for that sort of thing.

      The x86s from Intel or AMD will be fine for most stuff.

  17. Bring out yer dead. by stox · · Score: 0, Offtopic

    Large Man with Dead Body: Here's one.
    The Dead Collector: That'll be ninepence.
    The Dead Body That Claims It Isn't: I'm not dead.
    The Dead Collector: What?
    Large Man with Dead Body: Nothing. There's your ninepence.
    The Dead Body That Claims It Isn't: I'm not dead.
    The Dead Collector: 'Ere, he says he's not dead.
    Large Man with Dead Body: Yes he is.
    The Dead Body That Claims It Isn't: I'm not.
    The Dead Collector: He isn't.
    Large Man with Dead Body: Well, he will be soon, he's very ill.
    The Dead Body That Claims It Isn't: I'm getting better.
    Large Man with Dead Body: No you're not, you'll be stone dead in a moment.
    The Dead Collector: Well, I can't take him like that. It's against regulations.
    The Dead Body That Claims It Isn't: I don't want to go on the cart.
    Large Man with Dead Body: Oh, don't be such a baby.
    The Dead Collector: I can't take him.
    The Dead Body That Claims It Isn't: I feel fine.
    Large Man with Dead Body: Oh, do me a favor.
    The Dead Collector: I can't.
    Large Man with Dead Body: Well, can you hang around for a couple of minutes? He won't be long.
    The Dead Collector: I promised I'd be at the Robinsons'. They've lost nine today.
    Large Man with Dead Body: Well, when's your next round?
    The Dead Collector: Thursday.
    The Dead Body That Claims It Isn't: I think I'll go for a walk.
    Large Man with Dead Body: You're not fooling anyone, you know. Isn't there anything you could do?
    The Dead Body That Claims It Isn't: I feel happy. I feel happy.
    [the Dead Collector glances up and down the street furtively, then silences the Body with his a whack of his club]
    Large Man with Dead Body: Ah, thank you very much.
    The Dead Collector: Not at all. See you on Thursday.
    Large Man with Dead Body: Right.

    --
    "To those who are overly cautious, everything is impossible. "
  18. 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 ackthpt · · Score: 1
      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?

      Poor wage-slave peons like me call this "throwing good money after bad", but in business it's "an investment."

      perhaps if we glue enough feathers to this boat anchor it will fly!

      --

      A feeling of having made the same mistake before: Deja Foobar
    2. 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.
    3. Re:Let me get this straight by ceeam · · Score: 4, Funny

      To rephrase what somebody else wrote here:

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

    4. Re:Let me get this straight by Anonymous Coward · · Score: 0

      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?

      Because the people who use the Itanium have a lot of money. SGI is a typical company who uses Itanium. Their customers are military labs, the NSA, the NOAA, Big Science, and similar -- organizations with a lot of money, and a lot of pull.

      Make sense now?

    5. Re:Let me get this straight by Kadin2048 · · Score: 1

      Are you familiar with the phrase "opportunity cost?"

      What Intel and HP ought to be taking a very hard look at, is what else they could be doing with that $10B, that would generate more revenue than throwing it at Itanium.

      Given that I have no access to their financials, and I am assuming nobody else does (here on Slashdot) either, we're left to assume that they've considered and decided this. Which frankly doesn't speak very highly of their other projects -- if this is the best thing that can think of to do with ten big ones in capital, they may be in trouble.

      Humm, I wonder how my IBM stock is doing?

      --
      "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    6. Re:Let me get this straight by salimma · · Score: 1

      They want to keep AMD at less of a disadvantage, by throwing away the extra profits they're making from their x86 lines..

      --
      Michel
      Fedora Project Contribut
    7. Re:Let me get this straight by Jah-Wren+Ryel · · Score: 1

      Are you familiar with the phrase "opportunity cost?"

      Killing itanium is nowhere near free. You may not personally see them, but HP sells a lot of high-end systems and itanium is the only viable option for them going forward -- no way they could switch to Power, and FP performance of all the other commodity cpus isn't even close, even if they were to spend that $10B on brand new infrastructure for some x86 derivative.

      --
      When information is power, privacy is freedom.
    8. Re:Let me get this straight by jadel · · Score: 1

      I think SGI will be the company that will helped out the most by this.
      SGI makes a lot of Itanium powered boxen. They seem to have picked the itanic as their primary platform from workstations up to their big end NUMA machines - a decision that probably doesn't help their balance sheet. If HP and Intel can rustle up more interest in the platform it may even make them a serious contender again.....

  19. What are they thinking? by Slimy+Devil · · Score: 0, Troll

    Itanic is dead. RIP. Game over. Hasta La Vista (no pun intended).

    Game, set, match. Etc., etc., etc...

  20. what the f@#%& by NoGuffCheck · · Score: 1

    Seems to me that HP are better off keeping their piece of the $10 billion. You gotta spend money to make money but I fear this isnt the best way to improve their bottom line in the short term. Which is exactly what needs to be done since Carly got the shaft. I think they're taking their eye of the prize.

    --
    serenity now!
  21. Throwing good money after bad... by DoctorSVD · · Score: 1

    The Itanium admittedly has great FP performance _per clock cycle_, but that's about the only nice thing anyone can say. $10bn?!? Talk about throwing good money after bad!

  22. 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...
    2. Re:Apple by solios · · Score: 1

      The /. karma whoring, conversely, is priceless.

  23. An open letter to Intel and HP's board by loraksus · · Score: 0, Redundant

    Tell you what.
    You give me a billion dollars and I'll kick each of you as hard as I can in the balls.
    Ten times.
    I'm pretty sure that in 5 years each and every one of you will look back and wish you had taken my option.

    I'm trying not to be a jerk about this, but the person who posted the "bring out your dead" monty python skit hit the nail right on the head.

    --
    1q2w3e4r5t6y7u8i9o0pqawsedrftgthyjukilo;p'azsxdcfv gbhnjmk,l.;/
  24. who wants a WinCPU? by EllynGeek · · Score: 1

    so what's the point? Lack of 32-bit support nearly killed it out of the gate. Then they added software 32-bit emulation that sucked, and no one wanted it. Then they added 32-bit support in the hardware. Still nobody wanted it. Now they're going back to software 32-bit emulation. Sooo...how many enterprise servers really want to be running a WinCPU?

    I'm just a dumb IT droid, but this makes no sense. Unless the $10 billion is going for bribes.

    --

    we will end no whine before its time

    1. Re:who wants a WinCPU? by pUffY+86 · · Score: 1

      Its not for enterprise server systems, it was designed from the ground up for supercomputing, it actually has a pretty large role in that sector too. NASA's Columbia Supercomputer uses 10,240 Intel Itanium 2's. It was never intended for the mainstream server market where you only use 100's of these processors. It was intended for this use and this is where Intel and HP are most likley going to use it. Furethermore NOT ONE supercomputer out there is running on windows, it is too unstable and cycle hungry, the run on derivatives of Linux, Unix and other Cluster OSes.

  25. I bet IBM shareholders love the decision % by maynard · · Score: 1

    . ..

  26. In a (hazel)nutshell by ackthpt · · Score: 1
    Seems to me that HP are better off keeping their piece of the $10 billion. You gotta spend money to make money but I fear this isnt the best way to improve their bottom line in the short term. [...]

    You also have to spend money to lose money. The trick is getting something to come back. HP are already doing things with AMD processors so you gotta figure there's some real head-scratching going on among the workforce at HP.

    --

    A feeling of having made the same mistake before: Deja Foobar
  27. ha, I was right, it's a WinCPU by EllynGeek · · Score: 1

    "IA-32 EL is OS-based and is only available after an OS has booted,"
    http://www.digit-life.com/archive.shtml?2006/0125

    Betcha money it's not any form of Unix.

    --

    we will end no whine before its time

  28. 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
    1. Re:Tsk Tsk Tsk.. by o'reor · · Score: 1
      > 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.

      Wetting your pants on that one is such a fine way to start the day...

      --
      In Soviet Russia, our new overlords are belong to all your base.
  29. 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.

  30. 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.
    1. Re:Itanium isn't dead yet by poofyhairguy82 · · Score: 1
      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!).

      Which is why I think Intel gives THE best hardware support to Linux out of all the major hardware makers (Intel PAYS people to make open source drivers for their hardware often times- at most many of the others just give out specs). Intel has the only Directx 9 compatible video cards with open drivers and they have the best open wireless drivers.

      The happy marriage between Intel and MS of the 1990's is long gone I think after the whole Itanic thing.

    2. Re:Itanium isn't dead yet by Billly+Gates · · Score: 1

      Itanium was supposed to take over by now as powerpc took over the mk6800 for the mac.

      Infact Itanium was Intel's response to the powerpc chip and the growing threat of risc. IT was supposed to take over and was designed to do so under a false premise that manufactoring would limit transistor counts by now and things should be moved to software and cache/ram should be moved to hardware. What a disaster.

      Intel was expecting to make over $20 billion last year in Itanium sales and made only mere millions. No one wants it and it has no real market.

      The scientific community is even abandonding it for Opterons in supercomputers.

      I think Intel/HP should keep making it but no longer invest in it besides having a niche place in the market. THe market doesn't want it.

    3. Re:Itanium isn't dead yet by Billly+Gates · · Score: 1

      PS

      If you own the sushi suite you may want to change its name. Sushi is an opensource packing tool for NetBSD from Wasabi systems. They own the copyright for that. Just giving you a headsup.

  31. 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

    4. Re:I hope this works. by Anonymous Coward · · Score: 0

      Look at Itaniums performance on data dependent branches, it is underwhelming...

      Care to post a snippet of C demonstrating the problem, and I'll show you what today's Itanium compilers spit out? You seem full of hot air to me.

      Itanium greatly (like: insanely) benefits from repeated compile-execute-profile iterations of the benchmark.

      If that's the case, can you explain how the SPEC benchmarks "bzip2" and "mcf" benefit from such repeated optimization? Hell, even before+after figures would be great, to illustrate this "insane" benefit.

    5. Re:I hope this works. by Loopy · · Score: 1

      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.)

      They've been saying the same thing about apple for quite a while.

    6. Re:I hope this works. by Anonymous Coward · · Score: 0

      I'm not reading all those words!

      Shouldn't you be working?

    7. Re:I hope this works. by PantsWearer · · Score: 1
      Most of the other posts seem to have covered much of what's wrong with Itanium (I'm especially concerned about compiler improvement myself), but I don't think anyone has said anything about one of your assumptions about NOPs.

      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.

      Modern storage, both memory and secondary is incredibly cheap, but we've still got one problem where large binaries pose a problem: memory bus usage. The pipe from the memory to the processor is still the Van Neuman bottleneck and longer instructions make this problem worse. I don't have any numbers, but how often does the Itanium wait for instructions? This is pretty common on branch mispredictions on out-of-order execution processors.

      Frankly, when it comes to instruction size efficiency, modern x86 architectures are really excellent. It used to be the RISC held a good edge because, though it's instructions did very little, it's instruction reordering made so many more instructions execute simultaneously that it made up for the low instruction density. Then Intel did the impossible with CISC and made instruction reordering possible, through on-chip CISC to RISC translation. Basically, we're left with high incoming instruction density along with full reordering, which is the best of both worlds, leading to high instruction level parallelism.

      It seems to me that the Itanium went in the completely wrong direction when it comes to instruction density. Sure, it can run a huge number of instructions at the same time, but you're basically forced to ship NOPs along with them. Using your figure of 40%, that means, on average, 40% of your incoming instruction stream is complete fluff. Thus, 40% of your instruction bandwidth is basically lost.

      Also, individual EPIC instructions (at least in the Itanium's case) have a fixed width, so, like traditional RISC architectures, they're already pretty low in instruction density.

      --
      Be glad life is unfair, otherwise we'd deserve all this.
  32. $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.
    1. Re:$10 billion? I don't think so by PCM2 · · Score: 1
      Something smells fishy to me. $10 billion is alot of money for a marketing campaign.
      You misunderstand the nature of the investment. $10 billion is the amount of money currently on the table from all of the members of the Itanium Solutions Alliance combined, in terms of commitments to produce Itanium hardware, software, and support options. Probably some fraction of that amount will be spent on marketing, but most of it is going to be spent on R&D and manufacturing.
      --
      Breakfast served all day!
    2. Re:$10 billion? I don't think so by rolfwind · · Score: 1

      Read the article. It's not for marketing, but for continuing research and development. They are making such a large investment, because they believe a 140 billion market is a stake, claim they are being successful at pushing out Sun and IBM but want to accelerate the rate, and also, with their Itanium Alliance, believe there is a lot of money to be made on top of Itanium software solutions....

    3. Re:$10 billion? I don't think so by Anonymous Coward · · Score: 0

      Sure you can, aggressive tax planning, used to write off profitable activities, cutting tax, and maybe sink employee benefits/superannuation into the dog bits of the enterprise you want to hive off.
      Trouble is shareholders may see eps fall, and react.

  33. hear hear by Quadraginta · · Score: 1

    Man, that was a sweet processor. I recall comparing my spanking new DEC Alphastation to the Cray down at San Diego Supercomputing Center in 1995, and there was just about no difference. That machine flew.

    Funny thing how Digital's hardware dominance seemed to just dry up and blow away, tho'. I seem to recall in the 80s and 90s it was the place to be if you were a hot and ambitious hardware hacker. Wonder what happened?

    1. Re:hear hear by corngrower · · Score: 1

      It wasn't a problem with the hardware being slow, it was a problem with DEC missing the market. They were building top end machines when their company was built on selling midsized machines for manufacturing, scientific, and midsized businesses. That market went to the x86 and clones. The high end market didn't have the volume that DEC needed. DEC got squeezed out. Lack of vision on the part of DEC management is what killed the company. The company had the talent to build a microprocessor based system which could have hit the market before the IBM PC and with a much superior operating system, but the top management blew off the idea. DEC could have been the leader instead of a wanna-be in the personal computer market.

    2. Re:hear hear by Quadraginta · · Score: 1

      Yeah I know. But I wonder how that happened? It's hard to believe DEC managers were always fools. How could DEC attract such stellar engineering talent if management was populated by fools? Engineers don't work for idiots, at least not when they can do better, and the people who worked for DEC had their choice of jobs. Did something change? I don't pretend to know the answer at all, but I find the question interesting.

    3. Re:hear hear by corngrower · · Score: 1
      I think DEC management was too focused on what they had done in the past. Microprocessors were fairly new, and I don't think management had a clue as to how quickly they would advance in processing power. They were using medium scale integration with multiple big boards making up the processor.

      Management just couldn't grasp the idea of a computer that would be affordable to a single person. Computers had always been expensive, $50,000 or more machines. (and $50,000 was for something like a 16 bit machine with 256K memory and 10-20Mb disk space, low end in that time)

  34. How many chips have they sold so far? by WoTG · · Score: 1

    Here's a quick bit of math for thought:
    Let's say that Intel contributes half, so USD 5 000 000 000.
    Let's say that Intel nets USD 5 000 per chip (probably WAY overestimating sales price and underestimating costs)
    Intel would need to sell 1 000 000 chips to make this additional investment break even.

    This excludes opportunity cost, cannibalism of existing Xeon sales (though, it's probably the other way around), and probably a host of other things.

    It looks like sketchy math to me. To me, it seems obvious that the Itanium will be increasingly pushed into niche processing markets -- and even there, the few benefits that the Itanium presents will be continually reduced as x86 moves up market. Faster FP? Better RAS features? Better scaling? Those can and will be bolted onto Opterons (and probably even Xeons) over time.

    1. Re:How many chips have they sold so far? by Anonymous Coward · · Score: 0

      This excludes opportunity cost, cannibalism of existing Xeon sales (though, it's probably the other way around), and probably a host of other things.

      I'll pay you to run Intel :)

      The biggest opportunity cost is design engineers.
      There's not that many people on the planet that can design microprocessors. Yet Intel management, in their infinite stupidity, wants to deploy these engineers towards Itanium - a negative profit opportunity. Think of how much better off Intel would be if they put all those engineers (which includes the legendary ex-Alpha team in Massachusetts and ex-HP team in Colorado) towards an Opteron competitor.

      These people are moronic. The market punishes them for their mistakes and they go off and make an even bigger one.

      Does not compute.

    2. Re:How many chips have they sold so far? by Anonymous Coward · · Score: 0

      "Those can and will be bolted onto Opterons (and probably even Xeons) over time."

      The only thing I can think of is that Intel is hoping most of the developments made for the Itanium can be reused in other processors at a later time. They are in effect getting $5b from HP to do development; as long as it costs less than that to reapply what they do, they come out ahead.

      As an aside, it would be nice if Intel came out with some cheap CPUs that were really good at floating point. (Scientific computing tends to be more relevant to me than web servers or databases...it's probably not economical for Intel to address this market, but it would be nice anyways.)

  35. In other news .. flogging a dead horse.. by flyingace · · Score: 2, Funny

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

  36. Somebody has faith in Itanium ... by sierra077 · · Score: 1

    It's fairly obvious that the Itanium has been a failure. But then why so much interest from so many companies? From TFA, it's not just HP and Intel. I've heard that the architecture is good in theory, but bad in practice - and my own experience supports the latter. Maybe this is a desperate push to finally turn the theory into practice. Perhaps they should invest that 10 billion in a compiler that can actually support the Itanium's architecture.

    In any case, it's an uphill battle now - the Itanium is not looked upon favourably by most people I know. Right now, AMD has the most rational offerings for general-purpose computing and I wonder if IBM will market the cell (or a variant thereof) to the HPC market. Interestingly, both those designs are not dependent on the high-end market to survive. Anything recent that was dependent on that market seems to have failed - even the beloved Alphas. In that context, this investment does seem dubious.

    1. Re:Somebody has faith in Itanium ... by raftpeople · · Score: 1

      "and I wonder if IBM will market the cell (or a variant thereof) to the HPC market"

      Products are already on the market from Mercury Computer Systems:

      "Mercury's first Cell BE processor-based product is available for industrial, medical, and military markets. The Dual Cell-Based Blade offers outstanding performance for high-performance computing (HPC) applications. Performance scales dramatically when the application is distributed across multiple Dual Cell-Based Blades in IBM's industry-leading BladeCenter® platform or across the network."

    2. Re:Somebody has faith in Itanium ... by 15Bit · · Score: 1
      Itanic isn't the only recent attempt to move chip design forward and leave x86 behind, its just the highest profile. Mainly cos its been such a commercial failure. Remember not too long ago Transmeta unveiled a similarly radical design, also heavily compiler dependant. As with Itanium, part of the problem was that good compilers are hard to write. Sun are now heading down a similar road, marketing a cpu optimised for core applications. The world is changing here, and it may well be that Itanium was just too far ahead of its time.

      Personally I find it hard to believe that Intel would throw so much good money after bad if there wasn't a reasonable chance of payoff. And remember, the Itanium doesn't need to be a success - if significant aspects of the chip design make it into the next gen desktop CPU's, it'll pay for itself in a week.

    3. Re:Somebody has faith in Itanium ... by bytemonger · · Score: 0
      SGI put their future on Itanic, and look what happened to them? they are in the doorway of chapther11. Itanium has become a small nische market. There are just a few HPC apps available except for institutions running their own code.

      I've programmed the itanic, and it provides excellent float performance but poor integers, but lack of 3rd party software is killing it. Most people need integer performance more than float. Another issue is the unified 2nd level cache (both data and instruction into one table). If you can work around it and tune for the cache, then nothing in the world beats itanic on floats. The intel compilers also come with a shipload of performance flags. I have a doc called 'Itanium black belt compiler options' written by someone at SGI. It takes years to tune the code optimally. I've tested opteron, power5, power4, xeon and nothing beats it. Unfortunately one HP with a 1.6GHz itanium costs the same as a 2x dual core latest opteron from tyan with twice the mem, and the opterons have much faster memory latency.

      We will probably test the new SGI montecito low end blade server when it comes out, but it must be dead cheap to compete with opterons. But only as long as both RedHat and Suse keep their ia64 distributions, otherwise we do not have anything to run the distros on. In the end it is the customers that decides.

    4. Re:Somebody has faith in Itanium ... by multiplexo · · Score: 1
      SGI put their future on Itanic, and look what happened to them? they are in the doorway of chapther11. Itanium has become a small nische market. There are just a few HPC apps available except for institutions running their own code.

      Blaming SGI's troubles on the Itanium is ridiculous. SGI was heading downwards long before they decided to build the Altix line. In the early to mid 90s SGI had a great, high margin business selling lots and lots of systems for people who wanted to do CGI and visualization. This was very sexy and got SGI a featured role in Jurassic Park and everyone liked their funky, multi-colored workstations.

      SGI lost out in the late 90s because the company was focussed on graphics and they completely missed the e-commerce boom. Graphics are nice, but was anyone purchasing SGIs to run their Oracle databases, or for web servers, or for anything other than graphics? No, SGI was never a player in the e-commerce sphere and Apple, Microsoft and Linux systems eroded their high margin workstation business with cheaper machines that ran more accessible operating systems and which had a greater variety of applications.

      I hope that SGI can get their shit together and keep going in the much smaller supercomputing market. I have an Altix and it's a nice system, one of the best engineered I've ever seen, and the SGI folks I've dealt with have been uniformly excellent and my Altix running Linux is much nicer than the Origin 3000 running Irix (Irix sux!) it replaced. But time will tell.

      --
      cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.
  37. $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.

  38. For retirement by Anonymous Coward · · Score: 0

    No, no, no. It is, of course, retirement money for the original designers and even bigger money, or golden rain as I prefer to see it, for the big-honchos who financed it. They must be acknowledged for the untrodden highway they made.

    When the golden rain stops pouring over the decision makers, they might use the remainder to hire new designers.

    This all according to my own belief and superstition.

    Jokes aside, of course there will be overseas prgrammers! Even the CPU flagship Alpha was to a large extent made overseas; in Barcelona for that matters. No, don't be fooled by Fawlty Towers. Que?

    Even Rolls Royce are made overseas nowadays! Goddammit.

  39. Get organised by thsths · · Score: 0, Offtopic

    > I work a lot of overtime in a high-stress, tight deadline job. Once you get into that kind of downward spiral, how do you find another job?

    That's an obvious one: you quit this job before looking for a new one.

    > I'd quit if I had a choice, but I really need the money

    I wonder what you do with all the overtime pay? Sometimes a good career has to be organised, and this starts with having some money in the bank for situations like this.
    Proper planing can also reduce the level of stress you are experiencing...

    1. Re:Get organised by Anonymous Coward · · Score: 0

      why is this here? its the wrong topic. is there a problem in the DB or is this a troll?

  40. 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

    1. Re:Performance by Anonymous Coward · · Score: 0

      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.


      Oh please. The Itanic cannot compete with even old versions of POWER. IBM's dated result from 14 months ago is still 2.6 times ahead of Itanic's best showing.

      So when is Itanic going to get dual core? What will be the next delay or cancellation in the roadmap.

      Itanic's future: less like a roadmap and more like a funeral procession

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

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

  42. Makes sence... by Anonymous Coward · · Score: 0

    Apple will buy Intel and make it's own CPU's

  43. 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
    1. Re:AAAARRRRRGGHHHH!!! by Anonymous Coward · · Score: 0

      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.

      The Alpha EV8 never made it to silicon, and the Alpha EV9 never even entered the design stage. In short: you're full of shit. Then again, it appears that the latest "Madison 9M" Itaniums run a good 20-50% quicker than the last (EV78z) Alphas to be made.

      IOW, you're full of shit, with shit for icing on top. :)

  44. Wow, that's a lot of money. by Eric+Smith · · Score: 1

    I'd have thought that it was possible to rearrange the deck chairs for a lot less than that. Maybe it includes the musicians' salaries as well, though.

  45. Re:It is rather uninspiring to see all the negativ by Anonymous Coward · · Score: 0

    What really surprise me it that the Slashdot crowd give it such a negative attitude. Even though I have no direct interests in Itanium, I really enjoy continued investment in the IA64 architecture for many reasons. It is much more fun with more living architectures. I thought the Slashdot crowd was interested in technology, but sadly that seems not to be the case.

  46. 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.
  47. See also SGI. by solios · · Score: 1

    Everything you've said about processors? SGI used to be the KING of 3d graphics processing. What happened? Cheapass PC hardware caught up, broke even, and eventually lapped SGI's technology.

    The Alpha still rocks. It just happened to take the rest of the industry better than a decade to catch up.

    Unfortunately, there's no modern Alpha to flog the x86 with.... and all SGI has to wag over the competition is gigs of texture memory (for the price of a good sized whitebox render farm).

  48. 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.

    1. Re:Intel is up to something... by twitchingbug · · Score: 1
      This thing might be trying to compete with chips like the Ultrasparc T1.

      I was with you up until this point. There is no way Itanium is going to compete with T1. They are totally in 2 separate spaces. The T1 will deal with a lot of data dependent software - db accesses, web apps, etc. Itanium's only hope right now is highly parallelizable code that needs a lot of FP computing power. Also T1, i believe, is a lot less complex of a chip - it's even in-order execution (i think). I don't think people will confuse the 2.

    2. Re:Intel is up to something... by Anonymous Coward · · Score: 0

      As most of the die area of Itanium is cache, you could add a second core pretty easily. Or even a third and fourth die almost just as easy. What you would be limited by, is the bandwidth to the memory - Itanium needs a lot of it, as the EPIC instruction set isn't too friendly on the memory space

    3. Re:Intel is up to something... by syncrotic · · Score: 1

      The Itanium is in-order as well, isn't it? That's part of the reason for its small die area: much of the complexity is passed off to the compiler. It might not be a direct competitor to the T1, but I can see it adopting the same sort of philosophy: many small and relatively dumb cores on one die.

      You're quite right about the Itanium's strong suit being mainly parallel FP-intensive supercomputer-type stuff, but if you put enough cores on a die and they're fairly power-efficient, then the somewhat lackluster integer performance of each individual core might not matter.

      Meh, this is all just speculation - I'm certainly no expert here.

    4. Re:Intel is up to something... by TheLink · · Score: 1

      So what if the core is small. How well does the Itanium 2 perform without all that cache?

      Sounds like a whole load of rubbish to me. Unless the anandtech article author provides some facts I'd say he doesn't know what he's talking about.

      You say the Itanium 2 architecture needs lots of cache, so sharing it with other Itanium 2 cores with some fancy tech is going to make things so much better?

      The most recent Itanium 2 chip uses 410 million transistors (and the associated die area) and its current performance is crap compared to a dual core POWER5 with 276 million transistors, and a dual core Opteron with 233 million transistors.

      See my other post.

      It takes 1640 million transistors for an Itanium 2 system to be slightly faster than a Opteron system with 466 million transistors. And it's a lot slower than a POWER5 system with 552 million transistors.

      There is a correlation between transistor count and CPU cost and price.

      "perfect for multicore apps"? That's only if you can show me that an Itanium with 100M transistors or less will perform much faster than one core of an Opteron or POWER5.

      If you are going to have multi core CPUs with a budget of 1640 million transistors, which would be better?

      4 x Itanium cores, or 6 x POWER5 cores or 7 x Opteron cores?

      Lastly, if you are doing most real-world stuff, you need enough throughput to feed all those cores. Even if load up your FPU density so high that it theoretically does teraflops on the die, that's only useful if your data set fits within the die or the fast caches. Otherwise the chip will be spending more time waiting than anything.

      --
  49. Re:It is rather uninspiring to see all the negativ by groomed · · Score: 1

    Look, the only reason why Intel and HP keep sinking money into this dog is because they've already spent incredible amounts on it and have been telling everyone, for about a decade now, that it's the Future of Enterprise Computing.

    They seem unable or unwilling to face up to the fact that the Itanium is a complete albatross, and there's really nothing admirable about that.

  50. 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.

  51. Re:It's interesting to note that AMD will be close by RzUpAnmsCwrds · · Score: 1

    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/

    Ft. Collins has certainly seen a lot of high-tech in the last few years. Itanium was largely developed at HP Fort Collins, and now most of those engineers are Intel engineers. There's LSI Logic, Agilent/Agavo, HP, Intel, and of course all of the research that comes from a major university (CSU).

    Colorado could very well become the tech center of the mountain region - in the Boulder area alone, there's IBM (Niwot), StorageTek (Broomfield), Xilinx (Longmont), Sun (Broomfield), Level3 (Broomfield), Ball Aerospace (Superior/Louisville), NIST, NOAA, and quite a bit more. There's also Qwest, Lockheed Martin, Raytheon, Qualcomm, Kyocera, and a number of other companies with significant operations in the area.

    Interestingly, one of my friends worked at the former Celestica facility in Fort Collins; another works at HP in the Linux division.

    Major University + Low Taxes / Land = High Tech. That's why AMD is in Dresden.

  52. 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.

  53. The big picture. by Anonymous Coward · · Score: 0

    Granted, the Itanium was launched before the market/fabrication processes were really ready for it.

    I do not believe that is has deserves the flack it is catching in here recently. It's a killer FP unit, and in fact one of the fastest general purpose CPU's out there, it's current price/performance ratio is where the real problem lies. However I predict this will change in the near future, here is why:

    First off, the itanium is heavily dependent on huge and fast cache memory, there is no out-of-order execution, so cache misses are a bitch. This is much more pronounced in the Itanium because IA64 instructions tend to take up more than "just" twice the space (compilers for itanium tend to insert a lot of NOP's). Intel has during the last two years invested healivy in cache structure research, this has paid off, Intel has become extremely adept at producing cache memory. Further more if properly fed with data, the Itanium can processes 6 instructions per cycle against the opterons 4 AND due to its conditional oprations it can get the job done with fewer branches.

    Secondly, the itanium core is SMALL, with its L1 cache its roughly 21m transistors, which is about half the size of the Opteron or the Xeon, and with the decsion to drop x86 hardware support from the core, we might even see the Itanium drop below 20. Multi-core processors will be where the Itanium will shine, and multi-core processors is the way the market is going.

    IMO Itanium has time on it's side.

  54. OT: Re:Alpha by Anonymous Coward · · Score: 0, Offtopic

    I agree with your post. Plainly off-topic, but I could not resist your .sig!

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

    Of couse He could. Being both fully man and fully God he knew both sides of perfection and imperfection. Now we all know He was without sin; so if you think overheating a burrito is a sin, the answer is no; but then there's no accounting for taste. :)

    The proper formulation of the question is "Could God ... ?" exercise such power if He so desired. This is the power of the Trinity. It separates the spiritual world from the material and addresses the question of the spiritual in the material.

    This is all really well described in the first chapter of the Gospel of John.

    Oh, ya, I forgot. This is Slashdot. Moderate to -5: proseltyzing

  55. Re:Last Gasp for INTEL Big Iron? by Shivetya · · Score: 1

    I changed the title to better reflect the truth.

    Big iron is just fine. The deal is that Intel had delusions as to what it meant and tried to apply PC standards to a world which lives at a much higher level.

    PowerPC archietecture is alive and well in true big iron. It will even find its way into IBM mainframe technology. Server farms are not big iron, they are glorified PCs with a little bit more reliability yet suffer from all the issues PCs normally do.

    The big iron at work here, Tandem, IBM Mainframe, and iSeries have no appreciable downtime and the majority if not all recent hardware failures were transparent to all users. Hell some of the hardware failures are transparent to support staff as IBM usually calls first.

    A processor does not make you big iron any more than disk drives make a server. Its a mindset that isn't happening at Intel and one HP lost a long time ago.

    --
    * Winners compare their achievements to their goals, losers compare theirs to that of others.
  56. Intel and HP Commit $10 billion to Boost Itanium by digitaldc · · Score: 1

    What they are getting into Aerospace propulsion now?

    --
    He who knows best knows how little he knows. - Thomas Jefferson
  57. 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!

    1. Re:Itanium is a great processor by slipangle · · Score: 1
      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.

      This is the same conclusion that I and my colleagues came to in 1995 after sitting through an NDA presentation delivered by an HP product manager. He was very excited about it, but we knew it would never work. If you can't fix it in 10 years, why bother?

    2. Re:Itanium is a great processor by Anonymous Coward · · Score: 0

      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.

      You do know that Compaq "killed" Alpha because they sold it (and the people who worked on it) to Intel, right?

  58. BMW brake pad sensors by Ender+Ryan · · Score: 1
    BMW brake pad sensors are just a simple circuit. The circuit is closed once the plastic coating on the "sensor" wears down and makes contact with the rotor. Pads for BMWs include a new "sensor." The "sensor" consists of a wire connected to a little plastic coated piece of metal.

    Damnit. I had better replace those pads soon...

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
    1. Re:BMW brake pad sensors by Anonymous Coward · · Score: 0

      That's exactly how these things get started. Sure... let's just break the connection when the brakes get too low. Now we have to get the ECU involved to monitor the brakes. That'll require software coding and some extra ECU pins. Next get the Dashboard involved with a lamp for the brake indicator. Who's going to design the dashboard location for the brake indicator? Did I forget to mention now each brake needs wiring installed to route up to the ECU? Somehow manufacturing will need to add these to the wiring harness connections for install on the assembly line.

      How does everybody else do it? A metal tab on the pads.

      If you ever read through a BMW service manual (and are familiar with other manufacturers) there are more examples.

  59. 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.

  60. Are Colorado's clean air laws like Californias? by Anonymous Coward · · Score: 0

    If they're not, theres a chance your air's gonna get polluted :(

  61. for $50 million, I will stop calling it "Itanic." by swschrad · · Score: 1

    deliver in pallets of slightly used 20's please, to the lobby of my bank. details on request.

    --
    if this is supposed to be a new economy, how come they still want my old fashioned money?
  62. 24 Months to go before the death of Itanic by Spinlock_1977 · · Score: 1

    This is an old ploy. I'll bet they scrap the chip within 24 months. With Alpha, Compaq did the same - went public with huge statements of commitment to test the waters. In less than 12 months, they announced the death of Alpha.

    --
    - The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
    1. Re:24 Months to go before the death of Itanic by corngrower · · Score: 1

      Being that I today read an article about the new Itanium chip being released, I'd say you hit the nail on the head. They want the chip to sell well, so this is a marketing ploy to convince potential customers they'll stand behind the chip for years to come. Customers won't buy this thing if they see it as a dead end. Then they'ld have the expense of switching to another platform just a few years down the road.

  63. typical slashdot bullshit by Anonymous Coward · · Score: 0

    It's obvious that they know a lot we don't, but everyone here is too arrogant and pastywhite to admit that

    maybe

    just maybe there is a difference between what you read in a C|net article and what's available to the public, and what's going on in intel's labs, and within the company's boardrooms.

    You are forever on the outside track.

  64. sigh... mod parent up by stevesliva · · Score: 1

    Grandparent quoted (or invented) completely unsubstantiated claim about Itanium taking market share.

    --
    Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
  65. What is so good about Itanium? by dtjohnson · · Score: 1

    There doesn't seem to be anything very compelling about Itanium. It doesn't clock particularly fast compared with other competitive hardware, it only does 4 FLOPS per cycle like most other current processors, it isn't very compatible with other software, it's difficult to develop for, and it doesn't even have a nice looking case. WHAT is so special about the Itanium that keeps Intel pumping money into it?

    1. Re:What is so good about Itanium? by Anonymous Coward · · Score: 0

      There doesn't seem to be anything very compelling about Itanium.

      What with all the fanboyism about these days, you can sure be forgiven for that - it can seem like Itanium is just another processor, but it isn't.

      It doesn't clock particularly fast compared with other competitive hardware

      High clock speed is good why? (Do you look for clock speed? Buy a P4 then?)

      It only does 4 FLOPS per cycle like most other current processors,

      However, they are full 82-bit FLOPs, and unlike any other processor, the *latency* of a FLOP is just 4 cycles. That's right - an 82-bit precision floating point multiply and add, in 4 cycles. The FPUs on Itanium 2s are demons (and FWIW, the Itanium 2 9000 series does 8 FLOPs per cycle, by the way.)

      it isn't very compatible with other software,

      What do you mean? It runs x86 binaries fast enough - for those few where you don't have the source or can't buy a native version - it runs PA-RISC binaries faster than any PA-RISC chip, and if you have the source, it's trivial to recompile...

      it's difficult to develop for,

      This is bullshit. It's really, really easy actually. The fact that it's an in-order architecture makes the performance simple to predict when you write code, and the PMU makes it really simple to find performance issues once you're done building some software and want to start giving it legs.

      and it doesn't even have a nice looking case.

      Are you talking about the processor, or Itanium-based machines?

      WHAT is so special about the Itanium that keeps Intel pumping money into it?

      That's a long story, but basically:

      - Large cache
      - Demon FPUs
      - Large register files
      - Second-to-none reliability
      - Low design cost (in-order microarchitecture)
      - Low power consumption (just check out the 90nm Itanium 2 figures)
      - Compatibility: they can sell Itanium into markets (HP-UX, VMS, NonStop) that they simply cannot sell Xeon/P4/whatever into.

  66. Opteron RAIP by Nom+du+Keyboard · · Score: 1

    Opteron = Redundant Array of Inexpensive Processors. With this kind of money being spent on a rat hole I won't be buying any more Intel or HP stock anytime soon.

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
  67. Re:It's interesting to note that AMD will be close by smellsofbikes · · Score: 1

    That's kind of odd. Loveland was the first site for an HP shop outside of California back in '62, and after they moved here (to get lower-priced tech workers) they built a mini-tech economy that included LSI, Celestica, Flextronics, Advanced Energy, and scads of others in the area. But now, HP has shut the Greeley and for all intents and purposes the Loveland plants, is drastically cutting the Fort Collins plant, Celestica's been outsourced to Mexico, both Flextronics plants are long-since gone, AE is downsizing. I work right beside the big AMD design center in Longmont and we joke about how there are fewer cars there every day. I'm very surprised that they'd move into an area where high tech seems to be moving OUT as fast as it can, because they've created a localized expensive workforce exactly like they were trying to escape when they moved here forty years ago. At one of my previous jobs at a hardware place, I was working with five people I'd worked with before, every one of them at a different place, one at *two* different places, and as I was working there several other people moved through that I'd known from other jobs as all five of the people I mentioned moved on to other jobs. The nomadic tech community here is pretty cool, but feels incestuous sometimes.

    --
    Nostalgia's not what it used to be.
  68. itanic redesign by Anonymous Coward · · Score: 0

    Rumour has it that intel is going to bring out new versions of the itanic with RISC features such as hardware out-of-order and speculative execution to try to get the performance up to a reasonable level on non-scientific (i.e. business) workloads.

    itanic came from late 1970s supercomputer designs.

    intel wanted to take over the (64-bit) world with itanic and they almost managed. They, together with HP PHBs, convinced the technically-illiterate PHBs who ran SGI to cease development of their own 64-bit RISC CPUs. itanic was promising jam tomorrow and no one was going to be able to compete. itanic has been pushed into smaller and smaller niches as time has gone on. Once it was the 64-bit CPU to rule them all. Now it's just for "supercomputers."

    intel and SGI gave a 10240 itanic cluster to NASA. The competition was an Opteron cluster from Sun which was cheaper, faster, cooler, less power-hungry, so intel paid for it to save face.

    The UK Atomic Weapons Establishment just ordered an Opteron-based Cray for nuclear weapons research.

    If you want to see a VLIW design done right, look at the Transmeta Crusoe processors, or the Sun MAJC.

    1. Re:itanic redesign by Anonymous Coward · · Score: 0

      intel and SGI gave a 10240 itanic cluster to NASA.

      If that's so, why does the machine make a notable appearance in SGI's 2005Q2 financial statement?

      Allow me to humbly suggest you either call them on fraud, or admit you're full of shit. AMD astroturfer, are we?

  69. 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.

  70. The Itanium is crap by TheLink · · Score: 1

    The Opteron is much cheaper than 75% of the Itanium.

    So far I've seen a fair number of reports from people that the Opteron actually works much better than the Itanium for most real world tasks using real world system configurations. I haven't seen a single report saying otherwise (other than from PR announcements).

    A dual core Opteron only requires 233 million transistors and a 200 square mm die.

    Whereas a low-end 3MB cache McKinley Itanium 2 has 221 million transistors for _one_ core. The more recent 1.6GHz Itaniums use up to 410 million transistors taking 374 square mm (still one core)!

    So I wouldn't say the Itanium 2 is a better architecture for floating point.

    I bet that the Itanium 2 design is much better in parallelizable floating point tasks than non-parallelizable tasks. If I'm right, then that those very tasks will be fairly easy to run well across multiple cores anyway.

    The IBM POWER5 has 276 million transistors and IMO it makes far better use of them than the Itanium (of course the IBM eServer p5's 36MB off-chip L3 cache might help a bit too ;) ).

    AMD Opteron (TM) 180 2 cores, 1 chip, 2 cores/chip
    spec cfp2000 rate base=32.3
    spec cint2000 rate base=35.0
    transistors = 233M x 1

    AMD Opteron (TM) 280 4 cores, 2 chips, 2 cores/chip
    spec cfp2000 rate base=68.7
    spec cint2000 rate base=71.8
    transistors = 233M x 2

    AMD Opteron (TM) 880 8 cores, 4 chips, 2 cores/chip
    spec cfp2000 rate base=129
    spec cint2000 rate base=134
    transistors = 233M x 4

    IBM eServer p5 570 (1900 MHz, 4 CPU) 4 cores, 2 chips, 2 cores/chip (SMT on)
    spec cfp2000 rate base=125
    spec cint2000 rate base=74.4
    transistors = 276M x 2

    HP Integrity rx4640-8 (1.6GHz/9MB Itanium 2) 4 cores, 4 chips, 1 core/chip
    spec cfp2000 rate base=77.9
    spec cint2000 rate base=72.5
    transistors = 410M x 4

    Given that, I'd say there is really very little reason to go Itanium (especially since HP's commitment to Tandem, OpenVMS seems rather questionable, a pity actually).

    Either Intel is nerfing their Itaniums (by going single core with so many transistors for cache vs multicore with less cache) or their architecture just doesn't work well in practice. In any case, if you're going to pay a lot for non-x86, might as well go IBM POWER5.

    Otherwise, the Opterons are pretty decent. I'll leave the Intel x86 figures for someone else to do :).

    --
  71. Itanium was build to block others from cloning by kostaki · · Score: 1

    It's protected by extensive IP patents. That was its goal. Not to be innovative or great or whatever. Intel was afraid of the clones (AMD, Cyric, etc) so they had to build a new architecture that no one would be allowed to clone.

  72. Time to short by Philip+K+Dickhead · · Score: 1

    HMS Itanic.

    --
    "Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
  73. Time to replace HP's new CEO by Billly+Gates · · Score: 1

    I know I surely would if I were a big investor.

    How could they be so stupid?

    Even Intel mentioned they were expected by shareholders to make $26 billion last year with Itanium sales and only made sales targets in the mere millions??

    Not to sound flamebaitish but how many billions upon billions have Intel/HP invested in the Itanic errr ITanium? To me I see it as a way to say "Hey! We just blew billions into this project and were are going to get a return whether you like it or not!" and being totally ignorant about sunken costs or what the market prefers.

    For $1 billion they could resurrect the alpha and take over the whole market. IT sounds silly to say this but the alpha is the only chip that is fast enough to get corporate clients to switch and can run winx86 software nominally fast. If not then bring back PA-Risc for some of their high end systems.

    THe market has responded many times over and over again that they dont want the Itanium. Yet, stupidly and arrogance designed to protect a few executives self image (perhaps their job) means 10 billion more lost.

    I think Sun and IBM are getting quite a kick out of it.

    If a mere mortal known as a middle class person such as myself or 99% of those reading this made such a dumb decision about investments at work we would be canned in a second.

    Intel purchased a small Israeli chip firm to make the new Pentium Dou core that is used in Apple's powerbooks...err macbook pros. Very efficient chip and low power usage produced with a cap only in the mere millions. That just goes to show how poor of an investment it was.

    This makes no sense. Just like in the game of poker you need to leave the money on the table and walk. Its gone and your not going to get it back.

  74. Good for HP and Intel by Anonymous Coward · · Score: 0

    These CPU and systems are not your run of the mill white box generic PC server etc.
    These CPU's run and maintain alot of business infrastructure.
    If you've run a computer in a SAN enviroment, this CPU makes sense.
    The data throughput capability alone should convince most people what this CPU is intended for.
    If you want sustained DATA i/o that will saturate a SAN director switch, then this type of CPU will clobber your XEON/OPTERON cpu without the need to have multiple boxes to acheive something close.

    No Xeon/Opteron that I know have multi-rope I/O and when then do, they might be able to match this CPU

  75. Re:Last Gasp for INTEL Big Iron? by Bing+Tsher+E · · Score: 1

    PowerPC archietecture is alive and well in true big iron. It will even find its way into IBM mainframe technology.

    I think you mean the POWER architecture. 'Power Pee Cee' is Apple marketing jargon.

  76. Typical HP by Ralph+Spoilsport · · Score: 1
    They continue with lay offs and massive payments to the big wigs (scum), cutting down telecommuting (idiots), they have NO real technology vision beyond rebranding stuff from Canon et al who build their crap but use "INVENT" as their logo (hypocritical dorks), but they're willing to piss $10b away on a chip no one wants or needs.

    Brilliant. Carly's been gone for a while, but it seems the shit heads she brought on board are still making (stupid) decisions there. This Itanium/Itanic thing is just the latest round in the long slow HP death spiral.

    RS

    --
    Shoes for Industry. Shoes for the Dead.