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 I'm no programming guru, but it seems to me that the x86-64 architecture is a great one. In fact, the only thing that I could see being done to improve it would be to add more general purpose registers. I believe that the new registers are all GP (IIRC), but I think that makeing them ALL GP (even the older ones) would be good, and maybe bring up the number of registers to a good round 32 or something. Am I missing something glaring wrong? If you're going to toss out all of the x86 stuff (like ia-64), I think you should be able to emulate it in hardware about as fast as current x86 processors can. When Apple switched to PPC, couldn't they emulate 68k code about as fast (or at least faster than 1/2 the speed of) the fastest 68k chips?
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
So he is more likely to know what he's talking about.
Personally, I'm getting a bit tired of all the inane cynicism that passes for reflective commentary in modern society. While it's true that the world has its villians, it is more true that people often just hold opinions irrespective of their economic interest. I for one, trust that Linus is among these favored many.
(Not joking this time)
Sun has an interesting( biased) peace on Itanium. If I were buying a server I would avoid Itanium like the plauge. It is possible that Intel could even cancel the whole project and leave customers high and dry. Not to mention software availability is a problem.
I prefer the risc architecture. I like the idea of keeping things simple and efficient which is alot like structured programming. VLIW does not follow this ethic.
http://saveie6.com/
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....
I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering.
AMD is developing their 64bit chipsets with the desktop market in mind, as well as the server market. Intel has forgone the desktop, which will turn out to be a huge blunder. Especially when its already a determined fact that the 32bit emulation mode on AMDs line slaughters the 32bit mode on the Itanium.
I'm out of my mind right now, but feel free to leave a message.....
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?
Sure, but it doesn't really do it significantly better than some of the more common RISC architectures (Sparc, Power, Alpha), and it's a lot more expensive.
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....
Probably not, but a lot more desktops get sold than high-end servers. If AMD manages to get a toe-hold on the desktop with their 64-bit solution, the chances are a lot better x86-64 will migrate up the food chain than ia64 will migrate down.
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?
Well, that's the point. How useful is it really? What compelling reasons are there for using it in place of a x86-64 on the low end, or something like Power or Sparc on the high-end? All things considered, it really isn't a bad chip. But it is a solution in search of a problem.
One of my favorite all-time quotes from a flame war was about this topic.
"While they sit in ivory towers, the mongols are multiplying in the hills. Soon, the towers will lay waste and the hordes will have moved on victorious."
Of course he was talking about the ivory tower of PERL, and how the TCL was going to become the dominant force in scripting language. But I've loved the allegory ever since.
--------------------
OnRoad: Becuase hacking funner with a hacksaw.
I think the problems with the Itanium boils down to this:
1. The CPU's are insanely expensive. They make the majority of x86-architecture Intel Xeon CPU's look like a bargain.
2. Where are the server applications that take advantage of the Itanium CPU? They're not exactly widely available, to say the least.
3. Programming for Itanium is still a somewhat iffy proposition.
Meanwhile, AMD's Athlon 64/Opteron offers these advantages:
1. The CPU will definitely NOT be insanely expensive to purchase.
2. Programming for the AMD x86-64 architecture is not going to require kiboshing a bunch of legacy programming tools and starting from scratch--it is a straightforward process to convert today's programming tools to take full advanratge of the x86-64 native mode.
3. Because the programming tools are so readily available, both operating systems and applications for the Athlon 64/Opteron will be available widely by the time the new AMD CPU's are finally released for sale. Already, UnitedLinux is porting Linux to run in x86-64 native mode, and Microsoft is very likely readying versions of Windows XP Home/Professional and Windows 2003 Server that will run in x86-64 native mode.
Meanwhile, Intel supposedly has a 64-bit x86-architecture CPU codenamed Yamhill that has developed. However, given we don't know how Yamhill implements 64-bit x86 instructions Intel will have to do some VERY serious convincing to Linux kernel programmers and to Microsoft to write Yamhill-native code--and Intel is far behind the AMD efforts.
Not only does he work for a chip maker, he's like totally obsessed with the i386 architecture. I guess it's what he cut his teeth and and he's going to stick with it. But to think that no-one else has a use for it is very short-sighted.
He works for a company that doesn't build chips with the i386 architecture. Its emulated in firmwear, "code morphing" is what they call it. Its slightly slower than hardware but its worth the trade for power consumption.
I am betting he has worked with plenty of morph code, creating virtual cpus, subsets of the i386 chip, or different completely. This is akin to designing hardware, in software.
I can't see how him working for Transmeta hurt his understanding of processors. Seems like it would actually enhance his understanding.
Tequila: It's not just for breakfast anymore!
That doesn't mean it's the best solution. Merely the one that's going to win. Architecturally speaking, x86 is one of the biggest loads of crap to come along since...well...hmmm...I can't think of anything crappier off the top of my head.
Extreme register pressure. Segmentation models that make you want to retch. Hacks (PAE, anyone?) that leave any sane designer gibbering incoherently.
If you read the thead, Linus' main argument seems to be "to get good performance, all the other architectures have had to do complex things in hardware, so there's no real hardware simplification in going with a 'better' architectural design. Plus variable length opcodes are a natural cache optimization!"
I respect Linus a great deal, but he's talking out of his ass here. I agree that IA-64 may be best relegated to some academic's wet dream, but just about any of the major RISC architectures are big wins over x86. Intel and AMD have worked miracles with x86 to get it to run fast, but at a staggering engineering cost. The teams working on RISC chips tend to be a fraction of the size to come out with a high-performance chip. If the RISC houses had an engineering team of comperable size (and access to the same bleeding edge lithography processes) it would easily be worth an extra 25% in performance, minimum.
If you look in the embedded world, just about anything that requires serious embedded performance is RISC based (MIPS/ARM, mostly), simply because it decreases the engineering work involved by an order of magnitude. Plus, writing low level software for just about any RISC chip is loads easier than for x86.
Unfortunately, x86 is here to stay for the foreseeable future. Intel killed Alpha, not by buying it, but by doing a great job of pushing cheap x86 performance to the same level as Alpha, often surpassing it in later years. The same thing is happening to the other workstation-class RISC vendors, and, honestly, to Itanium, too. I don't see any reason to believe the march to x86 hemogeny outside the embedded world is likely to slow anytime soon.
Linux made him ... oh wait nevermind.
Transmetta makes a lot of ... oops there I go again.
Intel is a company that time and time again proves it knows how to make money. It may not always support the crowds it should (like /. readers and superusers) but they are still making money.
Sure there are lots of difficulties going to a new ISA. Especially at the server level. And yes Itanium has had some performance problems, especially in its first revision, but then again when was the last time you saw a company produce a 1st generation microprocessor and have it do well?
IA64 offers tons of advanced ILP concepts and OS concepts that, when correctly implemented, can increase performance drastically. (if your looking for examples, data speculation, control speculation, predication, registers with kernel access only, rotating register files, a much larger register set, etc).
The problem may be, it puts a lot of complexity into the Compilers, and compiler technology isn't good enough for Itanium yet.
But then again, what do I know, Linus has made more money than I have. I just like arguing the other side while everyone else screams about how the Itanium will die.
Sorry while I rant, but you just stomped on one of my nerves. (Unless your comment about neededing that much RAM was a complaint about Adobe or their direct *cough* compeitors -- sucks to be you.)
<Old Geezer Mode> In one case, not long ago, a fellow lab-rat Eric Mortenson had sold his research and tools to Adobe, but part of the poorly-written agreement said that he couldn't upgrade his work station. So he finished his Ph.D on a 386 with 32-MB of RAM, while the rest of us in the lab were using Pentium 3's, DEC Alpha's, and various SGI boxs. Eric's algorithms ran great on the newer PC's even though he couldn't develop them on the new boxes. Other with Adobe (NOT on that web site interestingly enough) needed the DEC Alphas (64-bit machines) with scads of memory and much more running time to do a similar implementation of Eric's algorithms. </Old Geezer Mode>
3D rendering doesn't take that much RAM. As a 3D graphics researcher and developer, I have worked with models where individual objects were multi-gigabytes (meshes+textures and volumes) but even then, having 1GB of RAM was more than enough for us to reach 20-30 FPS realtime on a box with NT4 and first- and second-generation 3D cards. Software rendering with very realistic detail was a little slower (3-5 fps) but was fine for writing movies. Progressive geometry & texture transmission, continuously calculated view-dependant detail levels, and other current and not-so-current research would solve the memory problems in 3D. Don't believe me? Go to Visualization 2003 and see if the leading researchers are finding RAM as their primary bottleneck. It is a bottleneck of course, but processing speed, caches, and the system BUS limitations are far more troubling.
As for video editing, you only need enough memory for the tools, a few frames, and whatever operations you are performing. In every case that I've had to do video editing, I've seen two classes of tools -- those that take gobs of memory and try to copy the entire video clip into RAM and end up thrashing for memory -- and those that intellegently figure out what is needed and use only the memory needed for the app.
An example of the first, an Adobe AfterEffects rendering a simple math function over time was only able to render 30-seconds because it wanted to buffer the AVI file in memory and ran out of RAM (2GB) after a several-hour rendering. An example of the second, a simple home-brew compositor that used the Windows multimedia API to write the AVI to disk -- the same machine and the same set of images required about 45 minutes to render the entire clip.
So instead of saying:
I would suggest you say " I need to buy tools that are properly designed and implemented for my class of computer. "
Frob.
//TODO: Think of witty sig statement
The key point about Itanium is that it is a horrible general purpose processor but it is a serious contender to be very good processor for supercomputing. It has very good floating point performance and the EPIC architecture is designed to be very good on Fortran, especially vectorizable Fortran which is very prevelent in HPC applications. What Linus said is correct in the context of Itanium as a general purpose processor, but its doesn't give Itanium the credit its due as a floating point supercomputer which is the only place its going to sell and is what it was designed for.
It will probably never be very good for most C and C++ apps. Pointer aliasing in particular will give the Itanium compiler fits. Unless you manually tell the compiler there are no two pointers accessing the same memory the compiler can't safely or effectively pack the parallel instructions in the VLIW and that is the essential to good performance in VLIW.
You do have to really question the sanity of some execs at Intel and HP for spending the staggering sums they've spent on Itanium. Supercomputing just isn't big enough a market for them to have any chance to recoup their investment in our lifetime and they aren't going to sell it in to the mass market as Linus said.
For a general purpose 64 bit processor to run existing C and C++ applications AMD is going to win hands down. But as many have noted its not likely most people are going to really need a 64 bit processor anytime soon so Intel will probably do just fine selling 32 bit x86 processors for a while.
@de_machina