Slashdot Mirror
Inside the Itanium
vanguard writes: "Extreme Tech has a detailed overview of the Itanium. It's fairly long but it's worth your time if such things interest you."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Real programmers who had to deal with the lack of registers. For instance, take the infamous Z-80. It had only 7 general purpose 8-bit registers, A,B,C,D,E,H and L, and you could use BC, DE and HL as a 16-bit register.
It also had 2 16-bit index registers, a 16-bit stack pointer and a 16-bit program counter. Wich, of course, shouldn't be used for calculations.
So you could count the registers on your hand. Ye good ol' times.
Of course, for some perspective on the nature of processor speculation, I point you to nearly any issue in Byte's print archive.
I registered my hate for Jon Katz
I'd have to disagree with the use of titanium in some cases. True, a lot of companies are using the name for the cool factor, but Apple's application of titanium as its outer case for its professional PowerBook line is both aethestic and functional.
The PowerPC G4 chip is a hot beast (nothing like the P3 or P4, but hot enough) that the titanium is used in part as a heat sink. Apple's application of the metal seems to get lots of oohs and ahhs as a result of this blend.
Vos teneo officium eram periculosus ut vos recipero is.
The most important thing about 64-bit chips is that they allow an address space of over 4GB. This is a real fully addressable >4GB space, not some 36-bit hack like the current intel 32-bit chips allow.
:)
In the EDA industry (Electronic Design Automation i.e. tools for making computer chips) we routinely hit the 4GB memory limit. 99% of EDA tools run on Solaris but EDA companies are slowly recompiling their apps to be 64-bit clean on Solaris.
Meanwhile Linux is picking up steam in the EDA world but the 4GB limit is holding it back. We're forcing into complex partitioning of our chips to break it into small enough chunks to fit under 4GB.
We need cheap (non-SPARC) 64-bit chips, say like oh AMD Hammer?
You've missed the point.
Complex compiling issues are NOT a result of CISC or RISC in this case. In fact, RISC is far easier to write an efficient compiler for than CISC. The instructions offered by RISC more closely mimic the kinds of basic operations compilers manipulate in the very back end of compilation. Register sets are usually general and very orthogonal, compared to CISC (Intel in particular) where you have very few registers and they all have special meaning depending on context.
The complexity in building compiling tools with respect to the itanium is all about VLIW, parallelization and scheduling. These are incredibly complex topics with many subtle features that make optimization and analysis very difficult.
Also, think again if you think compilers are written once for an achitecture and then set in stone -- 'once the damn thing is done' it definately will not be done. It will probably be buggy and poor at doing these new complicated tasks compiler writers have never had to do before. It will likely take a few iterations before the compiler tools start to show off the architecture. The question is which will come first, the latter or industry's frustration with poor performance out of expensive silicon.
Itanium is making the compiler do alot of work! This presents a gigantic challenge for compiler writers. My concern is with GCC. We all know that GCC does not produce the tightest, fastest code. For IA-32, this is not a big deal because there is only so much optimization that can be done with that ISA (instruction set architecture). However with Itanium, the compiler will probably affect runtime execution speed by 100% or more. Will the GCC people have the resources and expertise to handle IA-64 (Itanium)??
the real problem for intel is that the arch does badly for programs that are not cache hitters
they took one look at the people trying to do predictive memory loads and decided not too. this was a LONG time ago and now people have solved the problem so that most of the time you can get things from cache
IA64 fails to get things from cache too well (one of the reasons why they stuck such a large one on) so suffers from the latencey problems more than most
simple
regards
john 'try runnning spec marks on it' jones
It sucks, nuf said.
A bit more specific, look at the bottom of the article where it mentions the "use merced for development, mcinley will actually sell". And the fact that even Dell no longer sells Itanium.
Sanity check:
system specint/specfp cost
Hp server rx4610 342/701 $23k
AMD XP2000+ epox 8HK+ 734/642 $1k
Keep in mind that the Itanics are supposed to be for the server market, so the specint figures will more likely track actual performance. Intel has been claiming that McKinley will be a vast improvement (actuall claims seem to have been steadily downgraded from "dominate the market" to "actually sell a few" to "won't make management look like complete idiots"...). Present claims of McKinley performance are 1.5 to 2.0 times Itanic performance, i.e. unlikely to keep up with Athlon, let alone the hammer.
Why does it suck?
While Intel does know how to design processors, the architectures are annother story. Aside from the 8086 kludge, intel has produced such "successors" as the 432 and the 860. The 432 was even slower compared to the competition as the itanic, and the 860 was even harder to write a compiler for (and impossible to write an interupt handler, let alone an OS).
EPIC is supposed to be VLIW with enough "extras" to allow the compiler to write code that won't require out-of-order execution. It is also supposed to allow intel to create several generations of compatible chips (something hard to do with pure VLIW). Somewhere along they way they forgot that the point of VLIW is to make execution simple. The lessons of RISC and the Cray machines is that the more simple and clean an architecture is, the faster it can go. Check out how long it takes to explain the architecture, then examine Alpha and ARM. Granted, ease of explaining does not always translate into ease of design, but it ussually does, and certainly did in this case.
What now?
It looks like the architecture of the future is x86-64. Hammer should appear this year (maybe not for sale, but at least samples). Intel is claimed to have a project called Yamhill that adds AMD compatiblity to the next generation X86. Right now, any support at intel for x86-64 appears to be a CLM (Career Limiting Move and no, it is still a CLM to support it now even after yamhill is enabled). After McKinley goes down in flames (there doesn't seem to be a chance of anything else), it will be interesting to see how long it takes intel to produce anything AMD compatible. Assuming that the next generation of X86 was started after the Pentium 4 finished, that would place it about 4 years from now. By the time the politics get straightened out, that is likely the earlies option (rushing that job will just make it happen later).
Why x86-64?
Anyone familiar with the x86 architecture ussually runs away in horror at the thought of actually using/designing one. Having said that, the 386 architecture fixes almost all of the problems with the 8086/80286. The problems left are:
variable length instructions - this problem has basically disappeard, all modern high power CPUs have bigger problems than this.
insufficent registers - hammers doubles the number of registers (note that itanics 200+ registers become a hindrence if not fully used).
addressing size (32bits) - obviously hammer fixes this.
In summary, intel had a chance to create a usable architecture (anything noticably better than X86 probably would have worked), and would simply owned the market. It is possible that some PHBs thought that anti-trust laws might actually be inforced and then created an architecture too complex to clone. If so, they certainly did so, admitedly making one too complex to build themselves.
Scott
Many of the comments about compiler technology in this thread could be taken verbatim from discussions about RISC architectures 20 years ago. Or from the HLL (high level language) architecture discussions 30 years ago. (Anyone remember the cries for "closing the semantic gap" between processor's and languages? No? Point made.)
Hardware is getting more complex; it takes more sophistication to deal with it. Binding a (general purpose) processor to a language in order to make language implementation easier is exactly the wrong way to support a wider variety of languages. Making the most of a processor's capabilities is what compilers are for. That's what compiler writers get paid for.
That's not to say I'm in love with the Itanium. At first glance I found it a baroque rehash of old ideas. But time--and compiler writer's--will tell.
When Steve Jobs was asked about what he was envisioning regarding 64-bit processor adoption (related to the fact that at that time, IBM came out with the Power4 kick ass cpu), his reply was that it would take about 10 years for the common of the mortals (you and me mostly, but not him :-) to see 64-bit systems on the shelves at Fry's or CompUSA.
Given that it was coming out from the mouth of the CEO of a company that :
- can afford the move quickly and nicely (PowerPC architecture is clean compare to IA-64 + x86 and is 32-bit backward compatible).
- had successfully shifted the kernel to a clean replacement (less kludges) allowing the transition in a blink of an eye (ok, maybe 6 months)
- has a park of installed machines in places like labs (see gentech), and design studio.
- runs applications that would benefit the most are all in the Apple camp (A/V and number crunching apps like photoshop, maya and final cut)
- develops a big chunck of the major apps for its platform leading the way in term of design and adoption of new tech.
it would seem that we have about 8 more years of 32-bit glory or galore in front of us, before the current cpu architectures get displaced and eventually die.
Which 64-bit architecture will succeed is not clear today. Knowing that MS doesn't rush their OS out of the door to support the IA-64, it seems to be a little premature to tell.
PPA, the girl next door.
-- I feel better now. Thanks for asking.
Then came the Inanium. VILW, code bloat, ugly architecture, requires near-omniscience from the compiler, very tough to program in assembler, a power hog, and with mediocre performance. If anybody else had launched this, it would have died before first shipment. As it is, it's dying anyway. Dell dropped their Itanium workstation recently. The Itanium may end up as a niche product, like the forgotten i860, i960, and iapx432 processors.
I'm hearing rumors of a new 64-bit machine from Intel that's basically an improved x86, like the AMD Sledgehammer. That may be what actually gets used.