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."
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
Too bad HP won't spend $$$ to bring back the Alpha.
I miss architecture diversity....
seems just a bit too late. they should donate to help feed some starving children not starving platforms.
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/
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.
>"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.
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?
Anyone want to tie this into their $10 billion push?
[Fuck Beta]
o0t!
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!!!
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?
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!
A feeling of having made the same mistake before: Deja Foobar
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.
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
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.
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.
Itanium2 systems are among the top in transaction processing. asp?resulttype=all
http://www.tpc.org/tpcc/results/tpcc_perf_results
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
10 Billion? That means it is just as important to humanity as nuclear fusion? WTF?
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.
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.
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.
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)
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!