Slashdot Mirror
Linus Has Harsh Words For Itanium
Anonymous Coward writes "As a follow up to the earlier story "Intel: No Rush to 64-bit Desktop"... In words that Intel are likely to be far from happy with, the Finnish luminary has stuck the boot into Itanium. His responses to some questions on processor architecture are sure to be music to AMD's ears. Linus, in an Inquirer interview concludes: "Code size matters. Price matters. Real world matters. And ia-64... falls flat on its face on ALL of these."" Of course, Linus works for a chip maker ;)
Now, we all know that the Itanium isn't everything it's cracked up to be, and I think none of us at are wrong in blaming intel for coming out with a lousy product....
But, isn't one of those situations he mentions in the interview (namely, running a large database server) what this chip is designed to be doing?
As I recall, the IA64 isn't designed for the desktop user... In fact, desktop users probably don't even need 64 processing for a number of years still....
Yet we're attacking Intel for making the chip to fit it's niche?
Perhaps we need to be more fair in the context of the usefulness of the chip, instead of considering it in all contexts and criticizing it based on that?
"but speaking strictly from the technological point of view"
I think that was his point. It's great technically but it sucks in the real world. If its not practical its a shitty architecture IMHO.
I also think the x86-64 is a more viable solution as well.
----
Go canucks, habs, and sens!
Worse is better
although the original essay talks about Unix and the LISP machines, it just keeps being true. Linus talks about the "charming oddities", well there you go: worse is better. Try for perfection, and the real world will eat you alive.
I also think he's right about the masses being what matter; I think Intel is still thinking about the data centre, not Joe Sixpack, with Itanium.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
i have used several PCs/Sparcs and in all of them, before discarding, I have upgraded memory to 2x to 4x times originally it came with. We don't need more than 4 GB now; but if you were to buy a computer now, you need to make sure that you would be able to upgrade ram to 4x. This means if your need is greater than 1 GB, then 32 bit system is not suitable for you. At present, all my home and work machines (new ones) are ordered with 1 GB. This is at the border of 4x memory expansion possible with 32 bit system. So in a year or so, I will definitely not buy another 32 bit machine.
Linus isn't saying he won't let it in. He's simply saying that the thinks it's not a good arch based on technical merit. He'll let it in. He never said he wouldn't. He's just saying he doesn't like the way the chip was designed (what choices they made, etc).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
What are YOU smoking?
Optimizations done at compile time are far better than optimizations done at runtime. At compile time, more is known about the structure of the program, where the flow of the program will be going, and more time intensive optimizations can be done than ones done in realtime in the cpu.
Itanium is slower right now, but as compilers with optimizations tailored to it come out, it has the potential to kick every RISC processor's ass. The reason for this is that RISC processors are bogged down by doing the optimizations at runtime that Itanium doesn't have to care about. This means the Itanium will have the same or less stalls and more efficient use of the processor.
Go read up on compiler optimizations to see why cutting out the middleman of instruction sets is a good thing.
AMD is the wildcard. If x86-64 is the bomb and takes off like AMD is betting on it. Intel lost the 64bit war for many years. IBM and maybe even Sun will quietly (well sun doesn't do jack shit quietly) push x86-64 for the low end while IBM POWER4 and POWER5 and POWER6 down the road run the big end.
Basically Intel needs something like Sun to jump on it IA64 to really give it some credibility and they don't sound real eager to. IBM sounds like they are down for the fight. Alpha, MIPS, PARISC are all pretty dead; long term and relatively speaking. Meanwhile, if Intel doesn't get on the shit quick then they'll have to support x86-64 too and that's the real death blow to IA64.
As time goes by, computer languages are trending towards more dynamic behavior. This tends to favor things like JIT compiling and linking into already running programs. Fewer people are going to be able to afford the luxury of spending hours to preprocess their code to fit into an extremely static ("explicitly parallel") hardware model. This will be especially true when chip makers treat their rocket science static compilers as a separate profit center.
Not to mention, the CPU is the one that is actually in the position to know what optimization is needed right now based on the currently running data set. Given that there is usually a several year lag between the latest CPU developments and widespread compiler support, I'd go for a CPU that knows how to do its own tricks. (Hasn't the Itanium architecture been nailed down for almost a decade now? And we're still waiting on better compilers for it?)
For the expensive memory environment for which it was designed the VAX was fabulous. And it was designed to be scalable as well.
You can snicker at the CISC VAX architecture, but it ran multi-user in less RAM than many processors today have CACHE. Remember 2 MB of RAM was a lot when the 11/780 was introduced. 600 MB drives were considered HUGE and were the size of washing machines.
Its scalable architecture let a copy of VMS from the lowliest processor be physically mounted on the most capable and boot just fine.
It had BCD instructions too, not just string.
But Gorden Bell got a lot more right than he got wrong. And the compact and orthogonal instruction set of the VAX looks pretty good today.
Most home users are going to see a performance drop from 64 bits. 64-bit code needs 8 bytes to hold every pointer. This will serve to eat up more cache and memory bandwidth, which are already major bottlenecks for any CPU.
Unless you have a program that actually needs to work on more than 2G of data at one time, 64 bits buys you nothing but extra time waiting to move around millions extra of zeroed out upper bytes.
Some people need that much data in memory at once, but the average home user today doesn't. People typically mention video, but if there's one thing that's easy to stream in and out of a smaller memory space, it's multimedia data.
First of all it is not very smart to try to reduce code size by putting complicated instructions in the processor architecture.
A succesfull architecture may be used for 20 years, and there is no way you can know which complex instructions will be most usefull/popular in several years. And when you start making upgraded chips for a design, these complex instructions will be a real pain in the ass.
The x86 architecture is a perfect example - it is a mess and many of its instructions are not used at all. The x86 is succesful because the way history played out - it was put on the first pcs, and the incredible numbers of precessors sold allowed intel to put more development money into that architecture than any body else was able to put into theirs. And large initial investments, and large sales numbers mean that individual chip prices can be lower.
Nevertheless, the alpha and some of sun's chips can still compete with intel in the server environment, with much smaller investments and worse production technology. That basicly shows the weakness of the x86 architecture.
When you have multiple pipelines and multiple stages per pipeline the size of your chip will grow exponentially to the number and complexity of your instuctions. Eventually adding more pipelines will be pointless and then you are reduced to adding cache as the only way you can improve your architecture.
For a Risc architecture, multiple pipelines will cost less overhead and more can be used. Processor performance can be increased by adding more pipelines without having to increase speed.
Intel has the money and the clout to make a succesful risc architecture. It is brave of them to do it, but from an engineering point of view it is the only right thing to do.
AMD will support x86 because they do not have the clout to force a new architecture on the world. It is a completely understandable policy, but then again will result in worse performance (unless their engineers are somehow much more brilliant than intel's).
Of course the real world matters and in the real world almost everyone uses x86. But if someone can change that it is intel.
Without Windows for x86-64, AMD is dead. No, Linux will not save it. However, the moment Microsoft releases Windows for x86-64, Itanic is history. The market will overwhelmingly favour x86-64 because of the much lower price (I expect at least 3-4 times lower, cosidering that the Itanic CPU alone sells for over $3000), and perfect backwards compatibility. Itanic's ia32 support is so pathetically slow that it may as well not exist, so a move to Itanic requires you to replace _all_ your software, which ain't cheap, while x86-64 allows you to do incremental upgrades. So, taking simple economics into account, Itanic will go the way of that ship and AMD will emerge the winner... provided there is a version of Windows for x86-64. Without that there is no point of talking about "64 bit desktop" market because it just won't exist. So what is Microsoft doing?
___
If you think big enough, you'll never have to do it.
Yes, RISC programs tend to be longer (sometimes considerably) than CISC programs. There are actually two (main) reasons for this. First, as you mentioned, you need to replace single instructions (usually ones that do memory-to-register operations) with multiple operations (such as a load followed by an math operation). Second, the instructions themselves tend to be longer, since most (all?) RISC archetectures have exclusively 4-byte opcodes - usually something like 1 byte for the opcode, a few bits for flags, and the remaining for up to three arguments. (register numbers or immediate values). CISC archetectures have varying length opcodes, some a signle byte and some several bytes.
There are a couple of mitigating factors here. First, compilers are usually not very good at using some of the more complicated combined instructions, so they go unused, inflating CISC code to match RISC code. Second, careful optimization of RISC code can identify repeated or unecessary memory operations, and eliminate them. When the memory operations are tied to the arithmetic (or other) operation, that is not possible. Finally, since RISC archetectures generally have large register files and all registers are equivelent, fewer operations are needed to shuffle bits around to where they can be worked on, whereas i386 has a lot of operations that only work on certain registers (though far less than earlier incarnations).
I used to be a big fan of Intel cutting life support on the 386 archetecture, because RISC is so obviously cleaner and nicer. However, I have started to believe the AMD hype about x86-64, which is basically along the lines Linus talks about here. RISC vs. CISC doesn't really matter any more, and the i386 archetecture is not so bad. If you A) add some more general purpose registers, B) eliminate most of the remaining register usage restrictions, and C) Ditch the worst (looking and performing) FPU on the market in favor of almost anything else, you have yourself a very servicable archetecture. Extend the registers and addressing to 64 bits, and you have something that has a lot more room to grow. That is what the x86-64 is, and despite all the rumors that Intel has their own 64 bit extension to x86, if they don't actually release soon people will start to adopt x86-64 and they will be in the unenviable posistion of having AMD dictate the future of their product line.
I have heard frequently that something like only 5% of the transistors on the PPro core were tied to the "i386ness" of the core. I assume with the P4 that number is even less. It seems then that the instruction set is not as big of a deal as we would like to think.
The thing that puzzles me about ia64 is: if the whole point is to "make the compiler do it", and none of the fancy instruction reordering is done in silicon, why is it so expensive?