Slashdot Mirror
Intel Dumps Iitanium's x86 Hardware Compatibility
Spinlock_1977 writes "C|Net is running a story that Intel is going back to software x86 emulation on Itanium in order to reclaim chip real estate. (room for another 9MB of cache?)
One notable quote about x86 emulation: 'Basically, no one ever used hardware-based IA-32 execution, so better to use the silicon for something else,' said Illuminata analyst Gordon Haff. 'Of course, basically no one uses software-based emulation either, but at least that doesn't cost chip real estate.'"
if they are going to dump x86 compatibility, why not dump Itanium compatibility and just go back to Alpha?
Politics. Yes, Alpha is a much superior platform, technically speaking, than pretty much anything else out there today. But for Intel to turn their back on Itanic (thank you, Register, for consistently misnaming the Itanium in such an apt way) would mean admitting that the billions of R&D they spent on it was a waste. HP also has political reasons to not resurrect Alpha.
Damn shame, that. If they'd poured as much money into Alpha as they did into Itanic, they'd have a platform that would whomp all over everything currently in the marketplace.
Perhaps this is an indication that Intel has finally realized that their strangehold on the CPU market may be threatened by AMD? And that they will have to optimize and trim the fat off their products? Competition is good.
Still doesn't matter, because in 2006 recompiling a program with a native-code compiler targeted to a random ISA (for a given operating system) is practically free—especially if the program was written in a reasonable modern language.
If the Java VM is your beef, check out gcj. Sure, it still has a runtime system. But its performance overhead relative to compiled C code is almost always negligible or better.
This is offtopic but... I'm glad to see someone using MiB rather than MB, that makes things so much simpler because of the way metric prefixes work. I salute you!
What day is it? Could you please tell me?
If you have the time to hand-optimize your code, it blows anything out of the water. This means it's useful for simple number crunching, but not much else - more processors are generally cheaper than more coders. It was expected that compilers would improve by the time Itanium was adopted, but that hasn't really happened. (I read here that the hurd coders were able to make their Itanium message-passing routine TEN TIMES faster by doing it in hand-coded assembly compared to what a compiler churned out)
I am trolling
Actually, if you think about it, the Itanium looks pretty good heat/performace wise compaired to the Pentium D's, which have roughtly the same heat output.
Intel's biggest failure was taking so dang long to get the Itanium to market. I remember when it was annouced, and a short decade later the thing arrived. By the time it arrived things had changed quite a bit at HP, Intel and the computer markets in general.
business users typically run ancient software from companies or consulting comapanies that no longer exist in binary form only. COmpatibility is more important for Intel than a company like Apple.
People who buy pc's do so because its what everyone else buys.
Its a mess and I am glad I am not Intel. I bet HP has a contract forcing Intel to keep making the Itanium too. They killed the alpha for Itanium and its just astounding after what a few billion in sunkin costs can do to make sure you wont leave for something better.
I think Alpha had a much better chance of taking over. W2k beta3 was out at the same time of the x86 version and Linux and BSD already were ported. HP could keep VMS and their other oses without porting them to another platform. The alpha had great FX32 software and I think some basic hardare assisted x86 emulation but I could be wrong? I remember reading back in 97 that the emulation was as fast as a pentium 166 on the 250mhz alpha. Pretty impressive.
Some mass production to lower costs and more software resulting from Intel and HP being behind it could have brought the windows based software to the platform as well. Just like Apple by now I bet we all would be using alpha based systems. Intel would of had a strong edge over AMD as well as teh AlthonXP would be struggling to compete.
http://saveie6.com/
Yes it is, because MB means 1000 Kilobytes, and MiB means 1024 Kibibytes. Usually you're off by a factor of about 0.91 or 1.1, which can mean a lot. Please don't insult the functionality of accuracy. :D
What day is it? Could you please tell me?
As somebody that's trying to run a 64 bit linux installation, I must tell you that this software nirvana where the instruction set does not matter is far far away.
Plus the fact that modern processors do so much internal magic on the code stream that an "instruction set" is more of a transmission protocol than anything having to do with CPU internals.
This means anytime it misses in L1, the entire machine stalls waiting for the data to come back from L2/L3/memory. This is fine for applications where the compiler can figure out all the data dependences and schedule the code to hide these cache misses (i.e. scientific applications). It is not good for your run-of-the-mill GUI programs like Word, Firefox, your favorite email reader, etc. Out-of-order architectures like Pentium Pro/II/III/4 and Athlon hide L1 misses a LOT better because other (independent) instructions can execute while the cache miss is going on.
A few points brought up in the article that I'll respond to:
- Predication - Predication (conversion of if/else code with branches to branchless straight-line code using predicated instructions) is not limited to EPIC/Itanium architectures. Conditional movs (cmov) in x86/AMD64/EM64T are a watered-down version, but they suffice for a lot of simple situations such as the one the article brings up.
- Instruction Level Parallelism (ILP) - Sure, the Itanium can decode/execute/retire up to 6 instructions per clock. That's dependent on two things: a) the compiler finding 6 independent instructions to schedule every clock, b) no L1 cache misses occurring (remember, Itanium is in-order, cache miss = stall).
- ILP is dead anyway - CPU cores are much faster than memory. Any time you have to go to main memory for something, you take a HUGE hit in performance. Who cares if your CPU core executes 100,000 instructions in 0.00001 ns if it takes 100,000 cycles to bring a cache line in from memory? Memory bottlenecks are starting to dominate CPU performance (see this paper for more info), so single-thread performance is going to be dominated by how well the cores mitigate cache misses. Out-of-order cores can do this well (it's getting harder, read the paper), but it's difficult for in-order cores.
- Thread Level Parallelism (TLP) - Any benefits of TLP stated in the article will apply to dual-core out-of-order processors in the same way they will apply to Itanium processors.
- Power - Intel just came out with their dual-core mobile stuff. AMD will sometime before the summer. The article claims that performance per watt is superior for Itanium; that may have been true a year ago, but it's about to not be true.
- Floating point performance - Itanium is the fastest FP chip on the planet. However, a lot of consumer apps aren't floating point-intensive, they're non-FP apps like Word, Firefox, an email client. Performance of these apps, like I said before, is much more dependent on not having cache misses dominate performance. Plus, with SSE2/SSE3 taking over all the FP duties in the latest Athlon64/Xeon/P4s, and Intel and AMD concentrating their efforts on improving those functional units, I bet consumer-level FP performance goes up.
Now, one predicted trend for the future is for all architectures to move to simple, cheap, in-order cores, and put a lot of them on the chip to give increases in TLP without using a hugely complicated, expensive, lots-of-power-and-chip-area out-of-order core. From what I can tell, Itanium is a hugely complicated, expensive, in-order core, not exactly what we need to put 16 cores on a chip. Intel could easily resurrect the original Pentium core, retrofit SSE/SSE2/SSE3 to it, maybe add some runahead execution stuff (from that paper I linked to above) or maybe two-pass pipelining to mitigate the cache misses, and voila: a cheap, in-order core.Oh yeah, this is all academic anyway; backwards-compatibility (x86 has it, Itanium doesn't) is probably going to be the real driving force like it has been for the past 6 years.
They do, hard-drive companies use the metric standard when listing sizes, while Windows will read it in the ibi-prefix standard. Which is why you lose about 10% of your data capacity upon purchasing a hard-drive. :P
What day is it? Could you please tell me?
"I find is odd that Intel keeps backtracking to its 20 year old Pentium Pro design. Both of their recent high-budget designs, the P4 and the Itanium proved to be a flop to some extent, while the P6/Pentium Pro/PII/PIII/Centrino/Banias architecture has scaled amazingly well since its humble 200 MHz beginnings."
We hit the wall in single-threaded performance that was remarkably similar for all the various architechtures. I imagine the Pentium Pro architechture appeared at a time when it was possible to incorporate most of the features we've come to know and love in something approaching their current form.
"But Transmeta was the last memorable innovation, and since then everyone seems to be exclusively focused on cache megabytes and transistor sizes."
I'd say Cell and Niagara are pretty interesting. They don't have the general-purpose utility of other chips, but they're very good at what they're specialized for, and they're certainly interesting.
I rarely criticize things I don't care about.
"How much does that weigh?"
"Ham!"
Don't even TRY to critisize it.
It's not FOR you.
It's been a long time.