Slashdot Mirror
Itanium Problems
webdev writes "An article in today's NYTimes (free but...) highlights some industry concerns over Itanium. The author suggests the normal "what's bad for Intel is bad for the computer industry". Anyone know the power consumption for IBM's 64 bit effort GPUL?"
...friend!
I'm part of a team of people working on a largish supercomputer using itanium2. The things are fast fast fast. Much faster than i anticipated. it's special purpose I think, which is why it defies industry logic
-- Who is the bigger fool? The fool or the fool who follows him? --
I just read a story on msnbc.com about AMD's 64bit processor, I close the window, check slashdot and there is the story about Intels Itanium. Anyway here is the link for msnbc. http://www.msnbc.com/news/813950.asp?0si=-
In college, really poor, need a flatscreen.
http://www.hp.com/products1/itanium/performance/ar chitecture/speccpu.html
-Kevin
The IBM 64-bit processor is reported to be much lower power than the Power 4 chip it is derived from, and the actual chip is rougly the size of the Intel Celeron. See article.
We've ported chemistry simulation code to the pre-release ITA-2, and run benchmarks. There's not much like it, performance-wise, and on a cycle/dollar scale, it's in a class by itself. Smokes US-IIIs, walks away from the Alpha, and keeps pace handily with the Power4, at a more academicly-tolerable price. It's a good chip in its second incarnation, and has the misfortune to be introduced during a recession.
As always, the NYT ignored that you'll need the 64-bit address space for large applications, it has excellent memory bandwidth, and those customers requiring such a system weren't explicitly interviewed or mentioned. The heat issue is true, and that's it's one failing, but as with the Alpha, it will get better in time. (I still remember the rumors, pre-release of the Alpha that DEC was going to have to build a liquid-cooled workstation)
There's something even above compatibility (migration path) - namely Moore's law. The goal #1 goal of a CPU company is staying on Moore's curve. Now the problem with x86 is that it is a f*cked up instruction set architecture, and because of its monstruosities (8 registers ? stack-based FP ?) it has become a major hurdle in staying on Moore's curve. Good luck to AMD with their 64 bit thing ... I seriously doubt that their 64 bit chip will be any faster than their own Athlon (going from 16 to 32 bits registers is a big deal, from 32 to 64 not so much)
The Raven
The Raven
Getting ia64 optimizations intp gcc is not just a matter of pulling some code from icc and plugging it in. The truth of the matter is that gcc just isn't set up to do the kinds of aggressive optimizations they're doing in icc. Maybe in a few years it will.
I think he's very right. Take for instance SMP. A single threaded application running on an SMP system has no advantage over the same app running on a single processor system.
In the same way, most applications aren't even aware of 64 bits. So they will continue adding, multiplying, and addressing memory in 32 bits -- whether they be binary ports, or actually recompiled versions.
For the lazy man's migration path of using the same apps on a 64 bit system, there will be no advantage whatsoever of using a 64 bit system.
On the other hand, if you are recompiling, you might as well switch to the EPIC instruction set (Itanium), and get a defacto performance boost -- even if you don't port the code to be 64 bit aware... that's something you won't get even if you recompile for 64 bit CISC opteron.
And last, if you are refactoring, or re-designing your app for 64 bits, there is no migration path per se.
So I think it all boils down to: power consumption (for google), marketing strategy (ie. hyping strategy), and economy.
You know, you can download the compiler for evaluation purposes to actually see if there is a speedup in your application. The linux version is even free for non-commercial use.
> bear in mind that the orginal 8086 was for a while > supplanted by the 8088 for compatibility reasons
It was just a price decision. The 8088 can do all that the 8086 can, except it's memory bus was only 8 bit wide instead of 16. This made for a much cheaper machine to build (fewer wires). The performance difference was not very significant and the software was 100% compatible.
Intel Corp. said it failed to reach an agreement in a $250 million dollar patent lawsuit by computer- services company Intergraph Corp., which already was paid $300 million by the world's biggest chipmaker to resolve an earlier dispute.
some info can be found here:7 0,146182,00.html
http://www.intergraph.com/intel/legalpic.asp
and
http://straitstimes.asia1.com.sg/money/story/0,18
Today, Intel and intergraph anounced a break down in cour ordered mediation to resolve a quarter billion dollar patent infringement suit against the ITanium.
In July last year, Intergraph (www.intergraph.com) brought a lawsuit against INTEL alleging the basic design of the Itanium violates ateleast two patents they had held for ten years. Intergraph alleges the concept of software based instruction routining in highly parallel architechtures was developed for their C5 (aka clipper) chip.
Itanium basic design is based on a HP concept for highly parallel processing in which the order of execution on the chip can actually create race conditions for dependencies in calculations. This allows performance enhancements and simplication of handshaking harware, since basically the chip does not have to wait for the slowest operations. INstead the job of preventing race conditions falls to the compiler. The compiler must model how the processor will execute an instruction in the context of the other instructions the chip will be executing in parallel and then re-order the micro-code to prevent erroneous computations.
It would appear the methodology for achieving this was patented by intergraph for the C5 chip. The C5 chip project was eventually abandoned and intergraph parteneres with intel to replace the CPU in their workstations with pentiums.
We all know that intel was previously accused of stealing the ALPHA processor designs and that law suit was "settled" by intel buying out the impoverished ALPHA (dec).
This law suit is for 250 million dollars. which is about 5 % of the entire 5 billion dollar development const of the Itanium. Mediation talks have broken down so the Suit will presumable go ahead. If you are interested try a google search, there's lots of info out there as this trial has dragged on for over a year.
Some drink at the fountain of knowledge. Others just gargle.
iAPX432 was intended to be an Ada machine, with much debt to Multics for the imagined OS it would run. I think the ultimate performance was 50,000 instructions per second, on a par with the 8008.
kinda like the p-system was for UCSD Pascal... became the WD 1600 CPU, remember that one?
in the recycled ideas department, anybody have any luck with any of the Java CPUs?
(maybe I should have posted this to alt.folklore.computers)
It runs legacy ... code, but under a sort of emulation that cripples performance.
It is no more emulation than Athlon, Pentium Pro, Pentium 4, or any of the other current x86 CPUs are.
The performance of legacy code on Itanium is certainly less than stellar. But it isn't emulation like Transmeta's methodology or DEC's FX!32.
It is a microcode based method very similar to any current x86 CPU. (just much lower performance)
This is something we've seen before in Intel's Pentium Pro. Never heard of?
*snicker*
You really think people haven't heard of Pentium Pro?
Or that *I* haven't?
It's not like it's the 486SL.
It was a fairly successful product. Quite a few of those chips were shipped.
And it became the basis for many later Intel CPUs.
it's performance sucked for legacy code. Intel is doing the same thing again, and I doubt if they will succeed this time
It isn't the same thing.
It's a significantly different situation.
Intel isn't killing off Pentium 4 line of CPUs in favor of Itanium CPUs. And hasn't indicated any willingness to consider that.
They also haven't shown an improvement in legacy code on Itanium systems.
This is a different situation with different tactics being used by Intel.
I wanted to point out that the VLIW-like nature of EPIC isn't to blame for its power problems. I hope the Itanium doesn't reflect too poorly on VLIW, because it does generally scale to wider superscalar architectures than dynamic scheduling.
As you increase the number of instruction pipelines, linearly, the rate of growth of the logic needed to detect dependencies between the instructions and fill the pipelines increases much faster (at least a square?). Soon, the chip is dominated not by units performing the actual computations, but by scheduling logic. Kicking this logic out of the hardware and into software (where more fancy and elaborate optimizations can be performed, but where you have less information about things like memory aliasing) can make the hardware smaller, cheaper, cooler, and faster, and also makes room for more pipelines and registers. This is what VLIW is all about.
In fact, the primary way in which EPIC differs from the traditional VLIW approach (mostly for the purpose of binary compatibility, between different generations of Itaniums, but also for dynamic branch prediction, etc.) is that the scheduling dependencies are explicitly inserted in the instruction stream, but the actual scheduling is still done in the hardware. So, in compromising the pure VLIW approach, Intel made the hardware more complicated.
So, the direction of VLIW is the only practical way to scale instruction-level parallelism. It has the potential to beat CISC & RISC at price/performance, power/performance, etc. (for applications with a significant degree of instruction-level parallelism). Unfortunately, this comes at the cost of programming complexity and potentially binary incompatibility between different chips in a family (not a big issue, for embedded applications). The only question about VLIW is whether there's enough instruction-level parallelism in the kind of applications the processor is needed to run.
I think Intel is generally headed in the right direction, with the Itanium, and hope they ultimately succeed.
(I have no vested interest in intel or VLIW, other than that I have optimized code for VLIW architecture, before, and am interested in seeing ever-faster processors developed.)