Slashdot Mirror
Itanium Update
NegaMaxAlphaBeta writes: "For those of you interested in Intel's Itanium 64 bit processor, EETimes has a nice update article to let us know what's happening with this beast. With an 8 stage pipeline, as opposed to the 20 stage pipeline in the P4, clock frequencies are obviously not as high (~1 GHz). Other notable numbers extracted from the article: 130 Watts power consumption, 328 registers, 6 MB of onchip L3 cache ... quite nice (well, not the power thing). I'm sure many people can appreciate 64 bit integer ops; for me, it means single instruction xor for the 64 bit hash codes used in chess transposition tables."
Shades of the whole 486SX debacle?
...the Itanium product line will see its speed increase from 800 to 1 GHz, which is half the frequency of the company's fastest 2-GHz Pentium 4....Intel contends, however, that the faster front-side bus, more on-chip memory and redundant logic resources will more than make up for the processor's lag in clock speed.
We can only hope that this chip helps the media away from using clock speed as the primary (often only) measure of performance.
Is anyone else so completely stunned as me, that essentially everyone (except AMD) has rolled over and allowed the IA64 to be crowned heir apparent as the new high-end microprocessor? The Alpha is dead by acquisition, HPPA is dead by partnership, MIPS is lost somewhere in the low end, and Sparc and Power4 are both retreating upstream.
It's amazing that ANYONE can field the number of mistakes that Intel has, and get away with it. For some time now, their first-outs have been essentially flops:
Pentium: Remember the 5V room heaters?
Pentium: Then the 3.3V units with floating point bugs?
Pentium Pro: The ancestor of the Pentium II/III line was a good CPU in its own right, and worked well for Unix and OS/2. But it completely missed the market, performing terribly on 16 bit code.
Celeron: DeCeleron, until they put the cache back on. From another point of view, the whole Celeron program has been a disaster, either by its own crippling, or by revealing how overpriced the PII/PIII line is.
Pentium III: CPUID - A 'workstation idea' that once again missed its market. Maybe if they'd found a way to node-lock software that can't be used for machine tracing. Maybe that's not what they were after.
Pentium 4: Let's face it, this CPU is just plain uneven and imbalanced. After a round of redesign to even it out, just like with the others, it could very well be an excellent CPU. Tame the prefetch, expand the trace cache, etc.
Itanium: Didn't even make it out the door before spin-doctoring began. "Just wait for McKinley!" I've already heard one set of rumors that McKinley isn't going to *really* do it either, so just wait for IA64-III.
Is all this any better than the "Just wait for this new release!" that Microsoft keeps pulling? Though I guess Intel does generally get each family right on the second shot.
AMD has a good product, I just wish they were a little less mum, and had a better response than warmed-over P-numbers. I also wish we could hear a bit more noise about the Hammers.
The living have better things to do than to continue hating the dead.
(bolding is my emphasis)
To protect against heat-related system meltdowns, McKinley includes a programmable thermal trip that can throttle processor performance by 40 percent to cut power consumption. But the company sees that more as a safety net, not as an answer to thermal issues. "This should never be needed in a properly designed system," said Naffziger.
Actually I am very familiar with VLIW and I suggest you read up on some of the comments by the Alpha development team on Merced. You clearly need a second viewpoint.
;)
.C file for their entire project. Opting rather to make many .o's and link them together. The linker typically does not do optimization. The compiler attempts to, but often assumes uniform memory access latency (the linker typically decides the memory map).
You're saying the compiler has knowledge of registers, and what branch will be taken? Further you're saying the compiler has knowledge of the *current* memory structure? Latency of a particular memory fetch/store (whether the data is in L1/L2/L3/L4/L5 memory?). When DRAM refresh is going to hit (if ever). Or that an interrupt may come in randomly.
All this info is VERY useful for the processor to reorder its instructions to avoid a pipeline stall. But of course, you'd say the compiler knew all this detail ahead of time - right?
Further, the compiler typically does NOT have access to the entire program at once. Many, many programmers do not have one huge
And i'd really prefer to avoid optimized recompiles during VM page swaps. They take long enough as is. And really, on a decent system - you shouldn't be paging!
Tom
Well its fairly obvious that you are an expert on cpu design.
I've programmed about a dozen chips in both the games field and compiler-writing field, I don't design chips any more than Eddie Irvine designs racing cars. But I don't think I'll ever see him getting into a tractor for his qualifying lap.
Raw speed became less important for most applications, so intel added mmx to speed up multimedia.
What planet are you on? MS and Intel have conspired to make raw speed as important as possibe for years. I personally have been offered payment by Intel to produce slower software as part of their "everybody must upgrade" roadmap. MMX came as a direct response to the increasing performance of 3D boards which reduced the need for a faster CPU. Intel fear anything which reduces the need to upgrade so they tried to fight back with MMX. That fear led to the only sigificant addition to the instruction set since the 386.
Once a few quality compilers are around this won't even be an issue.
You grossly underestimate the difficulty of this instruction set. I doubt there will ever be more than one (ie Intel's) good compiler and I doubt there will ever be even one which is reliable and predictable.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"