What's Next in CPU Land after Itanium?

"I work for a major research organization. Of late a lot of the normal big computer companies have been visiting and preaching the gospel of Itanium. My question to them, and to the assembled masses here at Slashdot is what happens next when Itanium is real? My world view is that Itanium based systems will become commodity products very quickly after good silicon is available in reasonable volume. At that point, why should one spend $8-10k for that hardware from the likes of HP, Compaq, Dell and others when one can build it for $2k (or even less)? In other words, has Intel finally done in most of their customers by obliterating all the other CPU choices (except IBM Power4 [& friends G4, et al] and AMD Hammer) and turned the remainder of the marketplace into raw commodity goods? Lest you defend the other CPUs... Sparc is dead, Sun doesn't have the money (more than US$1B we'll guess) to do another round. PA-RISC is done, as HP has given away the architecture group. MIPS lacks funding (and perhaps even the idea people at this point). Alpha is gone too (also because of the heavy investment problem no doubt). Most other CPUs don't have an installed base that makes any difference, especially in the high end computing world. So what's next? I don't like the single track future that Intel has just because it is a single track!"

Comments

compilers

[avandesande]

Itaniums will become commodities when people figure out how to write compilers for them. That will be in about 10 years.

Re:compilers

[shitfit77]

You seem to miss the point on this a little bit. Although there will be compilers available, there is an extreme difference between a compiler and a good compiler. A compiler works, a good compile is able to utilize an architecture to its fullest (or at least close).

Re:compilers

[jmv]

Not likely, it would take a couple of weeks max for the first compilers to appear.

Sure, but the problem is how long before there are good compilers? That's one of the main problems with architectures like Itanium.

Re:compilers

[jgerman]

First compilers are the MOST useful compilers since they are the ones that will be used to create the later ones.

Re:compilers

[bmajik]

You overestimate the brilliance of compiler writers.

LIW and VLIW were tried before. They flopped, because compilers were dumb then. Compilers stayed dumb until midway through the RISC era. Now RISC and CISC are the same, compilers are reasonably bright, and intel is trying its own hacky LIW thing. The compilers are smart enough for a generation 1 LIW design to work, but there may or may not be any indication that they'll be smart. And as each successive subarchitecture of IA64 happens, the compiler will need to change or the chip will need to handle previous generation instructions. Intel is not true LIW in this regard - you should be able to run unmodified IA64-1 bins on IA64-2 chips.

So, some brains are still in the IA-64 chip, meaning the compiler wont have to be _as_ smart, but they'll still need to be smart, and you'll still need a new compiler for each IA64 implementation to get max performance.

Re:compilers

[Zathrus]

Not likely, it would take a couple of weeks max for the first compilers to appear

You obviously know nothing about Itanium, EPIC, VLIW, or pretty much anything else on this topic.

The issue isn't whether or not there's a compiler available. The issue is how GOOD the compiler is. In the case of a Very Large Instruction Word (VLIW) CPU like the Itanium, the compiler is the bottleneck for system performance. Why? Because the premise of these CPUs is that while they have a low clockspeed (750-800 MHz for Itanium), they execute many instructions per cycle - 10 or more. So while "slower", they get more done per cycle, resulting in a faster overall execution. It's up to the compiler to properly structure the executable machine code to take maximum advantage of this layout and keep all execution units of the CPU busy at all times, as well as reduce disseparate memory accesses and so forth.

The intial compilers that are released with these machines do it, but not as well as they could. In fact, compiler writers are still trying to grasp the issues with pipelining on modern CPUs and their much lower number of execution units, and this is without utilizing special instructions that explicitly do non-conflicting operations at once. We're still years away from writing fully optimized compilers for contemporary CPUs. And while there's been a great deal of work done on VLIW already (prior to Itanium), there's even more yet to be done. A decade for a "good" compiler is probably optimistic.

You may be wondering, what's the point anyway? If VLIW is so damn hard, why bother? Just ramp up that clock speed and get more CPU power! Well, that's nice, but it doesn't work in reality. We're starting to bump up against physical limitations in CPU speeds. Electrons are not magical particles that travel instantaeously. They are limited to slightly under the speed of light, which means roughly 1 cm per nanosecond. This doesn't seem to be a big deal until you realize that a 2.0 GHz CPU means each clock cycle is 0.5 nanoseconds. So if you have to fetch an instruction or data from main memory, and that memory is a mere 5 cm away, under optimal conditions you've just sat around for 10 clock cycles waiting on that memory to be fetched. This is ignoring the fact that there's propogation delays, latch delays, and other things. So go ahead, pump that CPU up to 10 GHz and waste even more clock cycles waiting on data. That or redesign the entire thing, expect the compiler to do the work and properly feed you data and instructions such that you can do 10x as much in the same amount of time, and all with no wasted CPU instructions.

That's the theory at least.

Reality is that not only does the compiler have to properly organize the machine code, it also has to have some idea of what the code is doing to do so. Compile the code w/ profiling, run the code against a "realistic" data set, then recompile it again feeding it the profile data. Many compilers can do this now, but it's rarely done. Because it's hard to guess a "realistic" data set, it's hard to acquire the same, how you expect the code to be used and how it actually is used are rarely the same, and there's more development time involved in all of this. So most companies don't bother. And despite what I said above, 2.0 GHz still hasn't reached the point where the CPU is sitting on it's ass more than it's doing work. Until we start approaching that point there's little incentive to put in the R&D time necessary to switch to a new CPU archictecture.

And, of course, on top of all of the above is the issue that Joe Sixpack will invariably see 2 GHz as faster than 750 MHz no matter what. Have fun with that one.

I don't think we need to worry just yet

[Indras]

Think for a minute how long we've been using 32-bit processors. If (and when) 64-bit becomes mainstream, I imagine it will be around for a LONG time, as it becomes standardized and slowly takes over a majority of the market. Also, we'll have the other contenders butting in with equivalent and cheaper options, like Cyrix (tried) and AMD (did).

Just because Intel will pave the way for mainstream 64-bit processors using the Itanium doesn't mean it will monopolize the market until it comes out with a 128-bit processor. No matter what, it will probably be years from now before we have to worry.

SPARC's death *greatly exagerated*

[AtariDatacenter]

Having recently participated in an NDA from Sun regarding the SPARC processor (and even with the knowledge I had walking into the meeting), SPARC is not dead or dying. In fact, I'd say that Sun squarely recognizes it as a strength. Their competition (HP for example), however, is wishing they didn't knife their baby.

As far as money to go another round, remember, Sun doesn't fab CPUs. What Sun does is design them, and they turn it over to Texas Instruments for production. And TI has their own reasons to keep up-to-date with the latest production technologies, so Sun doesn't eat that cost.

BTW: I really wish that I could talk about the SPARC presentation. I liked it a whole lot better than the NDA I attended with HP talking about their Itanic future.

Re:SPARC's death *greatly exagerated*

[AtariDatacenter]

Sun's strength isn't in the performance of its servers. You don't buy a Sun because you want the fastest thing out there. You buy it for the support, reliability, software base, and probably a number of other things. As long as Sun's processing performance is "on par" with competitors, it isn't going to be a liability.

When I talk with management about servers, they don't ask me which one has the fastest CPUs. They've got a "short list" of hardware vendors (IBM/Sun, then further down HP/NT).

Re:SPARC's death *greatly exagerated*

[wysoft]

Sun doesn't have to worry about raw CPU power because their machines are not designed to write Word documents or play a game of Wolfenstein. Compare a Sun machine to almost any PC out there and it will smash the PC's memory and system bus bandwidth. For the kind of tasks that Sun machines usually accomplish, that is much more important when it comes to the throughput that people buy Sun machines for.

Hell, most PCs don't even have enough PCI bandwidth to fully saturate a gigabit ethernet connection unless you have a totally bare PCI bus or a system which provides each PCI slot with its own dedicated bus, as most Sun PCI systems do.

Let's not even compare the stability, scalability, and worksmanship of PC and Sun hardware. That would just be unfair to 99% of the "business" PC workstations and servers on the market.

Itanium

[crumbz]

Given the tremendous capital requirements in building a state of the art fab along with the incredible amount of enginnering man-hours required to leap to the next level, I think we are seeing a situation similar to the one for airliners: Airbus or Boeing. They are the only two that matter because the cost of entry into the airliner market is so prohibitive. This does not necessarily apply to Microsoft and it's OS monopoly as the Linux community has illustrated. Mindshare and marketshare are not always linked.

I have hopes for Intel producing the worlds best microprocessors as that would benefit s all. Simply advocating a move to Itanium for marketing reasons or to meet revenue targets does a disservice to the computer industry.

Then again, they are in business to make $$$....

No, no, and no.

[hotsauce]

No, Itanium will not become commodity as soon as you foresee because compilers and software do not exist to make good use of it (some argue nothing can make good use of it [derogatory]).

No, Intel has not killed the competition. AMD is alive and well. The PowerPC family is on the verge of The Next Big Thing (G5). And the reports of Sparc's demise have been greatly exaggerated.

No, other vendors are not irrelevant. Hitachi makes killer chips for big iron, and looks set to increase that trend. If anything, the CPU market is looking less and less like a monopoly than before.

Intel CPUs will be killed by Microsoft's CLR

[eyefish]

It is my opinion that once Microsoft makes its Common Language Runtime a forced deFacto standard, and once they manage to implement it on other CPU architectures, they'll essentially have a hardware-independent Windows platform. Once that happens Microsoft will have sole leverage on the PC business. That means that Intel will NOT be needed at all for running future versions of Windows-compatible programs. Who knows, maybe this could spell a revival on new and innnovative CPU architectures, since they all will now be able to run the CLR. Side note: We *could* do this today with Java, but sadly Sun doesn't have the leverage Microsoft's monopoly does on the PC business.

Re:Innovation in the CPU business

[GGardner]

Nice idea, but keep in mind that static compilers are extremely difficult to create for Itanium. Performance results I've seen show that while the theoretical maximum for IA-64 is pretty impressive, the actual results static compilers are generating are not so hot.

Now, try to write a dynamic, JIT compiler for Itanium, which is even hardware than a static compiler. I haven't seen any java or CLR performance numbers for IA-64, and suspect I know the reason why. :-)

More importantly...

[Kerne]

A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?

Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu. :P

Using a 20 year old peripheral port on last weeks multi-gig cpu is like sucking a McDonalds shake through a coffee stirrer!

Re:Itanium vs. Hammer vs. All Others.

[Skirwan]

If I recall correctly 32 bit programs that are not rewritten for 64 bit run SLOWER on the Itanium than they do the equivalent Pentium line.

When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

Until Intel gets the Itanium cost down to the point where they run 32-bit code at equivalent speed to a Pentium at the same cost, Itanium probably isn't ready for the consumer market.

--
Damn the Emperor!

I wouldn't count out everyone else yet.

[jtshaw]

You talk alot about Sparc, MIPS, and Alpha in that question of yours. Yes, those are all relatively low volume products, yes they do cost a lot of money. However, the Itanium is almost like Intels version of those products, done in a slightly different way. Even though they are made in lower volumes they are still profitable because the people buying them will pay a lot more for a system. Sun can sell a 64-processor UltraSpac III system for in the realm of a million dollars and more. If you don't think they are making a nasty profit of of that you are nuts. That is why they keep advancing the technology.

People love to through buzz words like 64-bit vs. 32-bit and stuff like that but when it comes down to it what do you need on your desktop? If you are using your PC for basic development or coding there is not much to be gained from a 64-bit core at all. You don't really need anymore precision. If you are talking about scientific applications then maybe you do need the 64-bit core.

I am not saying that desktop PC's won't eventually go to 64-bit cores. However, even if you were to get a cheap Itanium right now it would perform no better, and possibly worse then your high end AMD and Intel x86 processors because few of your applications would take advantage of the core.

This question will be better asked for when Intel puts a processor on there desktop timeline that utilizes IA-64 technology.

Itanium? in $2k systems?

[orz]

You're not going to be getting an Itanium based system for $2000 anytime soon.

First of all, Intel has said ever since the Itaniums much-delayed release that it couldn't really compete and is primarily released to get some infrastructure ready for when the McKinley is ready (IIRC, it's scheduled for about 3 months from now...).

Secondly, the die size for the McKinley is HUGE. On todays top-of-the-line .13 micron process, the manufacturing costs are likely to be too high for this chip to make it into high-end workstations, let alone $2000 consumer computers.

Thirdly, the competition isn't dead yet. Sparc and PA-RISC may be dead, but Sun offers competition, and IBMs Power4 will be a decent competitor. Alpha does indeed look to have disappeared, but I thought I heard something about some Japanese company buying rights to some Alpha stuff, and planning on a big die shrink and integrating a large cache (which is all the Alpha really needs to compete, for the near future).

Fourth of all, the performance of even the McKinley is questionable. Compilers for it's IA64 instruction set are still quite poor, with little sign of the anticipated improvements. It's predecessors, the Merced/Itanium, was dog-slow at most tasks (though good at floating-point). The most recent benchmarks show the McKinleys 32-bit performance as terrible, though it's floating-point performance is supposed to be stellar, and its integer performance decent (when combined with an enormous on-die L3 cache...).

Anyway. Intel just likes the Itanium because the the instruction set is sufficiently complex that the prohibitive cost of designing a compatible would raise the cost of entry to the market enough to give them a more secure monopoly for the next decade.

Re:Itanium vs. Hammer vs. All Others.

[Mr Z]

When Apple transitioned from the M68K line to the PPC, they were in the same situation - 68K code would run faster on a 40Mhz 68040 than on a 40Mhz PPC 601. The reason consumers didn't mind was that the the PPC 601 started at 60Mhz (approximately the break-even point to the emulation layer), and (to the end user) didn't cost significantly more.

While that's a valid point, it also bears pointing out that Pentium IV is at 2200 MHz whereas Itanium is at 800MHz -- about 1/3rd the clock speed. That ratio is going to remain for awhile too -- McKinley will come out at 1000 MHz, while Pentium IV continues its mad march toward 3000MHz and beyond. You acknowledge this fact implicitly with your next statement (re: Itanium not viable until approx same speed at approx same cost), but I felt it'd be interesting to point out just how large a gap there is.

These ratios spell doom for hardware-level emulation of the Pentium on the Itanium. Unless Intel has some serious magic, having a 100% cycle-for-cycle perfect emulation of the Pentium III or even Pentium IV on the Itanium die will never run better than 1/3rd the speed of the real thing, since the fundamental clock rate is so far off. The only real way to get close is to do a software-level translation and get a boost from scheduling for the native hardware.

It's interesting to note, BTW, that HP's Dynamo project does a software translation of PA-8000 code targeting (guess what) a PA-8000 CPU, and rather than slowing things down, it actually gets 20% speedups! Ars Technica also did a piece on this. Perhaps that's why HP doesn't have hardware-level translation from PA-RISC to Itanium on the die like Intel does -- they (HP) are in a better position to just translate the PA-RISC code to IA-64 when needed. (Also, in the UNIX world, it's just simply less necessary.)

--Joe

The killer is custom-made systems...

[Kjella]

Rewriting standard applications to take advantage of the Itanium is one thing. However, companies that need a $10k+ server usually have programs that are specialized. After 20 years of the x86 standard there's a large codebase, although given a few improvements along the way. If you read the FreeDOS article a little while back companies were still running DOS in production systems, because it *works*. Porting it to Itanium will be a lot worse than porting it to x86-64 and Hammer. Let's face it, the hardware cost is usually minimal today. Software programmers however, are not cheap.

Kjella

you're thinking too far away

[Anonymous Coward]

You won't see anybody building an Itanium for $2K, since the chips cost more than that when you buy 1000 of them at a time.

Maybe 10 years from now, but that's too far off.

1) HP's PA-RISC is as dead as Intel's x86

2) Alpha should regain the speed crown with the EV7 for a while, so they aren't dead yet. They've just announced they'll be dead in a few years :)

3) IBM's POWER4 is the current speed king and is likely to be around for a long long time.

4) MIPS.. Aren't these popular RISC chips in the world due to their embedded use? (N64, Playstation, networking) At 500Mhz in SGI's machines they are pretty dead, but various MIPS chips are doing quite well in emerging areas. Infact AMD just bought a MIPS company.

5) Sparc has never been that great CPU vs CPU with the other companies, but I expect them to be around for a fairly long time still, just based on their installed base. Their customers never really bought on performance (otherwise ALpha would still be around!), but on service and reliablity. As long as they can provide good enough performance they'll be around.

The next Itanium is HUGE making it very expensive to produce (meaning you won't ever build a system for under $2K with one!), requires a LOT of optimization in software to get accepable perfomance (meaning it'll suck unless you run active profiling optimizations and I doubt most game companies will even do that), it uses a lot of power and creates a lot of heat (it makes the Athlon/P4 look like embedded chips!), and it isn't really compatible with existing software. Nobody is going to run Win98, WinXP, or even GNU/Linux on it on the desktop.

The next Itanium will be more popular than the last, but it won't even register on people's radars as it won't provide the best performance, it won't have a bunch of software written for it, and it'll be expensive. Apple will sell more iBooks than Intel sells Itaniums for the next few years.

Re:Itanium vs. Hammer vs. All Others.

[Locutus]

> Only time will tell. Remember the Pentium Pros

the ONLY reason the Pentium Pro didn't catch on was because Microsoft released a 16bit OS and told everyone it was a 32bit one ( Windows 95 ).

SCO Unix, OS/2, and to some degree Windows NT ran quite a bit faster on the 32bit optimized PPro when compared with the same clocked Pentium.

Because of Microsofts great PR, even Intel was caught off guard and scrambled out a hack called MMX to give the appearance of progress in the CPU market. While the MMX based Pentiums were getting press/air time, Intel was hacking at the Pentium Pro core to get it to run THE 16bit OS (Windows) faster. That was the Pentium II.

IBM did some speed tests of OS/2 on the PPro and in some cases they saw a 100% speed increase on the 32bit optimized PPro.

This reminds me of the 7degrees from Kevin Bacon reference. It seems that many failures in the computer industry are only about 3degrees from Microsoft. And never is the failure do to competition but more likely, marketing and market control. IMHO.

The PPro was a darn good CPU. It finally took 32bit-ness seriously though about 10 years after the 32bit i86386 was released. As much as I like the simplicity of RISC, Intel will never get the Titanicium off the ground and AMD/Hammer will force Intel to follow their lead with an extension to the i86 instruction set into 64bit land.
IMHO.

LoB

Re:Itanium vs. Hammer vs. All Others.

[boopus]

While 800/2200MHz is a large difference, you fail to mention something that everyone here should know by now, that clock speed does not equal performance.

Clock speed does not equal performance. This is a fact of life, especialy with 20 stage pipelines and the like. AMD and Apply have been trying to teach this to the world, and on the surface most geeks understand, but they don't beleive it in their hearts.

Now, I'm not saying that the PIV won't be faster than Itanium for a good while here, and I honestly have no idea if it will be or not. We just need to stop using Mhz as our comparisons unless we're comparing the same chip.

Peripheral communication.

[Christopher Thomas]

A fast CPU is nice, but how about upgrading the rest of the standard PC architecture and peripherals to the same level?

Weren't we all suppose to be using high-speed serial connections by now instead of a cocktail of SCSI (1/2/3, wide, fast, hold the mayo), IDE (ATA-33/66/100), parallel, 8 bit serial, USB, Firewire, PS/2, PCI, ISA (which is finally disappearing), etc. Heck, I'd be happy if the motherboard ran at even half to a third the speed of the cpu. :P

The good news is that USB is well on its way to completely replacing serial and parallel ports, and that PCI has been the One True Bus for the past couple of years now. Everything south of the southbridge is slowly fading away.

IMO, if we'd switched to 66 MHz 64-bit PCI years ago, we'd have no further problems on this front. In practice, PCI-X may finally be pushed through by Intel, and that will serve most internal communications needs. Motherboard chipsets are modular enough that it doesn't really matter what flavour of IDE/SCSI/firewire your drive is hanging off of; the drive controller is just another PCI device to the processor. You have enough bandwidth and DMA functionality on PCI bus to handle it.

The only peripherals that are currently bottlenecks are RAM and the video card. RAM is handled by upgrading the memory bus every couple of years. This is easy to do, because peripherals don't care what happens on the other side of the northbridge. The video card was handled adequately by the hack that is AGP (64-bit 66 MHz PCI would have been a much better idea, but that wouldn't have given Intel its nice AGP port to license).

The only peripheral that *might* be a problem in the future will be the network card (when gigabit cards finally come into vogue), and that will probably be what forces motherboard makers to put wider/faster PCI on to midrange boards and not just high-end boards.

In summary, this is less of a problem than it first appears to be.

The only serious bottleneck for performance is RAM latency, and that's not because of legacy peripherals.

Not to rain on your parade...

[Chris Burke]

This is exactly why 'virtual machines' (VM) or 'Just In Time' (JIT) compilers will eventually replace the current series of compile to asm compilers.

Actually... Java/.NET and JIT compilers are exactly why "Merced" or "Itanic" isn't well suited for the very things it was supposed to be good at. You see, for a VLIW machine like those, the degree of compiler optimization required to achieve good performance is much greater than for a traditional RISC-ish machine (in which I'm including x86, for reasons I'm not going into). Essentially, to get maximum performance requires a great deal of compilation, profiling, and compiling again. This is all front-end overhead on your process. The whole idea behind JIT is that it's supposed to be fast, and occure when you download new code... But now the opposite is true. At this point, you're just as well off using a traditional-style compiler/profiler that produce traditional binaries.

Sorry. No VM utopia here.

SPARC performance

[Anonymous Coward]

First, go to the SPEC web page at
http://www.spec.org
Then, go to the TPC web pate at http://www.tpc.org

The performance of SPARC processors lags far behind
the performance of x86 and PowerPC processors.
The latter 2 processors (and their successors)
are the winners in the performance battle.

Sun's decision to sell Intel/AMD-based servers
running Linux is basically an announcement that
the SPARC processor will be retired within 10
years. Whenever a pro-SPARC person issues FUD,
he never supports his claims with objective 3rd-party
data.

SPeed of ...

[leuk_he]

I think you are talking about the speed of electricty, which is much slower than the speed of light.

By the way the speed of light in matter (glass) is slower that the speed of light in vacuum.

And to answer your question: Yes.