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 ;)
Itanium 2 is a great architecture. I don't care what Linus says about it. Sure, it is not cheap to buy or to deploy, but speaking strictly from the technological point of view, Itanium2 kicks a$$ in its range.
Was recently considering leaving the CPU business altogether. I wonder if the groundswell of support that is slowly building around their 64-bit CPU has changed their minds? Of course, it appears that they have "bet the house" on the Hammer and barring any disasterous product launch or systemic defects they are positioned well. Damn, if only I had a couple of grand to gamble in the stock market.....
There's Crusoe products out, available on the consumer market, priced at reasonable points.
They delivered a revolutionary product. It's up to the consumers now to choose to make use of it or not.
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.
As much as we depend on intel to push cpu manufacturing techniques to new heights, they have fallen down in the desktop market anyway. Ive lost count on how many new units they've added for poor lowlevel optimizers to keep up with. This with the slap in the face of reduced instructions per tic in the p4 so they could juice up the multiplier and sell "faster"mhz cpu's at double the price is more than enuf for me to stop watching them. Im far more interested in the new power5 coming out of IBM for a 64bit architecture to pay attention to. BTW, what ever happened to alpha 21364? is a 64bit cpu really newsworthy?
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/
Desktop users need at least 64 bit memory registers real soon now. DDR memory is fairly cheap ($100/GB in 512MB increments). 32 bit processors top out at 2GB of RAM without resorting to trickery.
Plus, when it comes to processors, technology develops features and then software develops around said features, not vice versa. Once there is a 64 bit desktop processor, software companies will develop 64 bit software.
Heck, using VS
-- Terry
The Inquirer.com isn't exactly a bastion of responsible reporting.
It doesn't look like an interview took place at all. It looks like they took some choice quotes out of context from the kernel development mailing list to spur some pageviews.
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!
Back when it was released, it was roundly maligned for offering shitty performance for Win95 users. "Buy a Pentium 233MMX" all the magazines screamed.
Well, the PPro turned out to be one of the best chips of its day, and the 200Mhz version performed within 5% of the Pentium II 300mhzs that were released 18 months later. I still have dual-PPro system running my CVS/MP3/print/etc. server.
Linus may be a god in the linux software universe, but I wouldn't discount Intel on this just yet.
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.
One reason Linux achieved stability years in advance over other "free" operating systems was because Linus took a bottom-up approach to system design. He started with the capabilities of the processor and then worked his way up from there.
The results were magnificent. The June 1992 issue of the German computer journal C't rated Linux as the most stable and crash-proof of all Unix operating systems. This is no shabby feat, considering the Linux's tender age, and formidable competition over which Linux triumphed, such as Irix and Sun OS.
Wrong. They design chips to improve scores on benchmarks. Otherwise you wouldn't be able to tell they got better.
Yeah, that's a given. I was just trying to point out that the Crusoe is already a 128 bit processor. So you won't be seeing a 64 bit Crusoe any time soon. Maybe a Crusoe executing instructions intended for an X86-64, but that's just an extension of the code morphing software. Even then I think the new astro chip would be more likely for that application since it looks to be meant for high density low cost blade servers with more punch than the Crusoe.
And you know, it doesn't do a half bad job. If only someone around here know vax enough to do anything BUT the planetarium shows...
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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.
Uh, Itanium 2's really aren't _that_ expensive, are they, at least compared to the lot you stated? I thought that an HP I2 workstation could be had for $8000, which isn't too bad for a 64 bit workstation. New Alphas certainly aren't cheap either, I have no idea about the latest Sparcs and Powers.
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
Benefit? That's easy... anyone that owns a digital camera.
Because you'll be buying a new one eventually... and in a couple years, you'll be buying 20megapixel digital cameras for $400. In other words, all your favorite geeks will have one.
And they'll want to edit these pictures on their computers. You wouldn't think that would need so much memory...
But.
Try it with 10 pictures at once, cause you want to see which has the best overall shot of everyone in your group standing in front of your friend that had a cool wipeout skiing.
You make a couple minor changes in 7 of the pictures, adjust color balance, change brightness, red-eye reduction, stuff like that. Your image editing app of course has multiple undo. (Don't they all?)
You copy a few of the images around, shoving them through the clipboard.
4 copies each (multiple undo, remember) of 10 images each at 80MB per image (32-bit color on 20megapixels...) that's... 4x10x80MB = 3.2gig of ram you just used.
Just for editing 10 pictures from your $400 consumer digital camera.
Now do you see why you want a 64-bit cpu that handles more than 3gig of ram for a single process?
(Yes, I purposely assumed that a simple "adjust color balance" requires a complete seperate copy of the image for undo, and it probably doesn't... but you get the point now, don't you?)
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
Take my grandfather for example. He worked as a transportation lawyer, back in the bad old Interstate Commerce Commision days. The ICC was created to regulate railroad monopolies, but was eventually coopted by the railroads to keep out trucking competition. In order to establish a new shipping route, you needed to prove to the ICC that there was a "need" for this new shipping route. Clearly, it was an absurd, anti-competitive system. My grandfather retired shortly before the industry was deregulated. However, to this day, he still believes that the ICC was a good thing, because being dependant on its existance for a job made him a believer.
The point is, when you have an economic interest in something, it can start to affect how you think about things. The wealthy tend to want tax cuts, and the poor tend to want spending increases, but most of them are probably not conciously supporting those positions for their own selfish ends. They truly believe that what's good for them is the right thing for everyone, it's a natural justification process for humans, and I wouldn't think less of Linus for the tricks his subconcious might play on his mind
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Would you prefer to have eight registers and a single byte copy- block instruction, or 64 registers and have to replace that copy-block instruction with (*gasp*) three simpler instructions?
You obviously know much more about cpu architecture than I do, so perhaps you could help me with something I don't totally understand: I don't doubt that RISC architechture is simpler, but isn't the executable code for a RISC cpu much larger than the code for a non-RISC cpu? For some things that can be done in one instruction on a CISC cpu, it takes several on a RISC. This would seem to me to take both more code for a program and be more intensive on the system bus by transfering the extra instructions. Am I wrong?
Why is this moist???
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
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.
Do you have any data to back that up?
According to this press release, the current record for the TPC-Cbenchmark on a 32-way machine is held by an NEC server with Itanium 2's.
Does Linus really get off on trolling or something?
I guess you can attribute his anti-Itanium stance to the fact that he collects his paycheck from an x86-64 licensee, but that wouldn't explain all the nonsense he spouts on the gcc mailing list, his opposition to kernel debuggers (because people who use debuggers aren't 31337 enough), etc.
The fact of the matter is that the Itanium line delivers superior performance at a lower price than its competitors, while maintaining that elegant architecture that Linus decried.
I've never run NT on Alpha, but my understanding is that Microsoft took the easy way out and ran NT basically as a 32-bit OS. Linux, OTOH, fully supports 64-bit and has done so ever since the Alpha port matured. Microsoft finally had to bite the bullet and fix their 32-bit-isms when then came out with Win2k for ia64, but that was years later.
The Alpha also gets you on unaligned memory accesses - if you and your compiler are not careful, you can force some very slow OS traps. I wouldn't be surprised if your applications were slow partly because of this.
Hmmm, what's not to like about Digital Unix? I always thought it was quite nice, as proprietary Unixes go. It was slower than Linux, due to its microkernel layer.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
When I say 3D rendering I don't mean openGL/DirectX rendering....I mean full raytraced, reflection/refraction with global illumination, complex shaders, etc. With scenes as complex as I'm working with, I'm still looking at rendertimes of upwards of an hour per frame.
And as for video editing. Take a 1920x1080 (max HDTV) clip in raw 1 targa per frame format, add gradients, filters, masks, particle effects, 3d camera movements and lighting, and tell me you can buffer more than a few seconds in RAM. Don't believe me? Go download the demo version of Combustion from Discreet and try it.
I'm out of my mind right now, but feel free to leave a message.....
There is no chance of seeing a Power 4 or 5 in an Apple machine. They are IBMs high end server processors.
The PPC970 however is a different matter. Based on the Power 4 core with AltiVec, minus the on chip level 3 cache and multiple cores (though going back to multiple cores is a possibility when they improve their fabrication to 90nm from 130nm)
Don't blame me - this
The computer industry has come to expect that Morre's law not only applies to processor speed but also to memory. Anotherwords, there has been an a doubling in the amount of memory approx. once every 18-24 months. A home/small office computer in 1979 contain approx. 64K of memory. Now, 24 years later, it is expected between 12 to 16 iterations will have taken place. In reality, the industry is between 13-15 iterations where several workstations come with 512 Megs of RAM upgradable to 1 Gig and Dell is already shipping workstations with up to 1.5 Gig of RAM. While you might argue if anyone needs that much memory, such an arguement should also question if anyone need a 2Ghz or 3Ghz computer. As computer speed increases, the amount of memory also needs to increase otherwise the usefulness of the increase speed will exceed the amount of data available to take advantage of it. The bottom line is that if the data is not available in memory then the additional clock cycles should be considered as nothing more than additional NOOPs.
.Net IL-code and the purchase of Connectix, they may be positioning themselves for the possiblity of releasing a Windows for PPC. This will provide MS an architechure to build from with a more proven track record than IA64 and without several of the limitations of IA32. At the same time, the purchase of Connectix would allow them to provide legacy compatiblity with IA32 code.
So, given the current trend of increase in memory on workstations, it would not be surprising if there is demand for workstations to exceed 4GB of memory by 2006. Aside from the ever cludgy PAE work-around, Intel does not seem ready to deliver such a workstation. At the same time, IA64 is not preferable to proven architechures such as SPARC or PPC for large databases and does a poor job in performing as being backward compatible with IA32. Thus, it does not fit well in a niche in the current server enviroment and will not be ready soon enough when the workstation enviroment demands it.
What I find the most interesting that no one seems to be discussing is that MicroSoft seems to be trying to remove their dependence on Intel. MicroSoft already showed that they no longer are dedicated to Intel when they provided support for AMD's 3D-Now. With their push to move from Win32 to
Intel was founded 1968 and AMD in 1970, so what was your point about AMD being "so young"?