Intel and HP Commit $10 billion to Boost Itanium 272
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."
It's interesting to note that AMD will be close by (Score:3, Interesting)
Itanium vs. Ultrasparc T1 (Score:3, Interesting)
True but can they compete with the UltraSparc T1 [sun.com] (which has 32 threads compared to Intel Itanium's 2 threads)?
Re:Last Gasp for Big Iron? (Score:2, Interesting)
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.
Re:Alpha (Score:5, Interesting)
Could Jesus microwave a burrito so hot that he himself could not eat it?
Apple (Score:2, Interesting)
"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
Re:Alpha (Score:5, Interesting)
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.
Re:Alpha (Score:5, Interesting)
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.
Performance (Score:4, Interesting)
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
Re:Alpha (Score:3, Interesting)
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.
ITER? (Score:3, Interesting)
AAAARRRRRGGHHHH!!! (Score:2, Interesting)
Re:Ah, capitalism. (Score:3, Interesting)
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.
Re:Let me get this straight (Score:3, Interesting)
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.
Re:Alpha (Score:3, Interesting)
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...
Intel is up to something... (Score:4, Interesting)
Recently an article [anandtech.com] 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.
Re:Alpha (Score:3, Interesting)
- 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.
Re:Itanium vs. Ultrasparc T1 (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.
Re:Last Gasp for Big Iron? (Score:4, Interesting)
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.
Don't forget what happened to Digital's AXP/Alpha (Score:2, Interesting)