Oracle Claims Intel Is Looking To Sink the Itanic

Blacklaw writes "Intel's ill-fated Itanium line has lost another supporter, with Oracle announcing that it is to immediately stop all software development on the platform. 'After multiple conversations with Intel senior management Oracle has decided to discontinue all software development on the Intel Itanium microprocessor,' a company spokesperson claimed. 'Intel management made it clear that their strategic focus is on their x86 microprocessor and that Itanium was nearing the end of its life.'"

Comments

Sparc

[Gary Franczyk]

Now that Oracle owns Sparc processors from Sun, there is no reason for them to help out their competitor.

Re:Sparc

[mbkennel]

It's cleverer, and assholeyer than just saying that.

Old Lawyer's trick.

Instead of saying the obvious, i.e. "We won't support our competitor's (HP) fastest computers because we make hardware now" Oracle spreads FUD about the longevity of their competitor's product line by virtue of leaking information from anonymous sources in their competitors' sole supplier.

Even if Intel and HP completely deny it, their customers will be thinking it all along.

Re:Sparc

[blair1q]

x86 is a small part of what's in a modern x86 CPU.

There's hardly any good reason to choose anything else over it, either. You can't beat it on performance the way Alpha did. PPC lost its simplicity long ago (and comes with some annoyances that make me wish it would just die).

Intel's latest stuff is the best that ever was. Nobody else does or ever has come close.

Re:Sparc

[Anonymous Coward]

Intel is looking over its shoulder at ARM right now

That's a given. When you look over your shoulder, you can't help but see your arm.

Re:Sparc

[schmidt349]

There's hardly any good reason to choose anything else over it, either.

Well, yes and no. Certainly in the space between the notebook computer and any but the mightiest supercomputers there's no reason at all not to go with x86. But in the mobile processor space, where ultra-low TDP is the order of the day, ARM has a big leg up on x64. Intel sold out their Xscale division (which was only ARM 5 anyway) and now they're losing this increasingly important segment of the market.

I'm not counting Intel out by a long shot in that race, but ARM is the new hotness for most geeks.

Re:Sparc

[pavon]

Unless of course they're telling the truth.

Intel is strongly denying Oracle's claims that Itanium is near end-of-life. So it looks like more Oracle FUD, and probably intended to harm HP-UX rather than Intel.

Re:Sparc

[hairyfeet]

Well ARM is a hell of a lot less power using but it is also a hell of a lot less powerful clock for clock, so it evens out doesn't it? I mean sure in a cell phone where its main job is running a highly specialized OS, with tons of little support chips to help it out it does great, but I wouldn't want to do my day to day desktop computing on it.

I never did understand the Intel VS ARM comparisons because it made as much sense to me as comparing a Peterbuilt and a Kia. Sure the Kia is gonna get a hell of a lot better gas mileage but I sure wouldn't want to try to move into an apt using only a Kia to haul my furniture. You try one of those AMD or Intel ULV netbooks and comparing it to the little ARM netbooks is like night and day. I could easily see myself doing most of my day to day on the X86 and not getting frustrated, whereas anything not expressly thought up and prepared for by the ARM netbook OEM and it is welcome to slow town.

So while the Itanic will go down as just another failed Intel experiment, like that ARM based chip they tried to get everyone to switch to in the 80s, I really can't see X86 going anywhere, especially once AMD solved the 4Gb barrier with the X64 extensions. The little specialized devices will stay ARM while the general computing will stay X86.

I'm sure there will be a few crossover niches, such as ARM for specialized servers which stress low power over everything else, but for the rest of the jobs where performance matters I just don't see ARM stepping up to AMD or Intel quad levels of performance, not without killing the low power selling point. It is just one of those things you can't get around, faster equals hotter and more power usage, whereas slow chips with less complexity use less power.

Re:Sparc

[Darinbob]

The problem is that the x86 is like the living dead. It's an ancient architecture which had a really bad architecture when it was new, and is now being held together through duct tape and an oxygen tent. Yes it's very fast, but it's very expensive to make it that way too. It works because Intel has tons of resources to throw at it. It is saddled with decades of backwards compatibility issues as well, 16-bit modes, segmentation, IO ports, and other things that no one uses anymore if they can help it. It requires tons more support chips than many embedded CPUs. The real reason x86 should die is that it's an embarrassment to computer scientists to see this dinosaur still lumbering about.

ARM on the other hand has some decent designs. It's not low power because it was designed to be low power, but because it's got a relatively simpler RISC design, and because it was easily licensed for people to fabricate so it got used in a lot in low power designs (ie, ARM core included as part of a larger ASIC. But there are faster ARM designs too, and with the same resources that the x86 has it would be really great. ARM is not inherently a "small chip". The problem is trying to compete head to head with x86 when everyone knows it will lose. So it's high power designs are not intended for PC desktops, but for specialized purposes.

Internally the modern x86 is really a RISC at heart anyway. But it's got a really massive support system on top of that that converts the older style CISC instruction set into a VLIW/ RISC style that's more efficiently executed in a superscalar way. Just like the original RISC argument, it makes sense to try and rip out that complexity then either use the resources to make things faster or just leave it out entirely to get a cheaper and more efficient design.

Anytime a better design is out there it seems to be clobbered in the market place because it just doesn't pick up enough steam to compete with x86. This is why alternative CPUs tend to be used for embedded systems, specialized high speed routers, or parallel supercomputers. Even Intel can't compete with itself, Itanium isn't the only alternative they've tried. It's not just performance either, most unix workstations had models that ran rings around x86 but they were expensive too because of low volumes sold.

The public doesn't understand this stuff. Sadly neither do a lot of computer professionals. All they like to think about is "how fast is it" or "does it run Windows"

The analogy with cars is wrong. X86 isn't a Peterbilt truck, it's a v8 Chrysler land yacht with a cast iron engine, or maybe an gas guzzling SUV. People stick with it because they don't trust funny little foreign cars, they feel safer wrapped in all that steel, they need to compensate for inadequacies, they feel more patriotic when they use more gas, etc. It's what you drive if you don't want to be different from everyone else.

Re:Sparc

[mcrbids]

And this segment is *important* because already, I do as much browsing and web-surfing on my Motorola Droid 2 Android phone as my fire breathing Intel Core i7 laptop computer.

Remember that x86 started out as the cheap chip on the block that was "good enough" for basic stuff that little people could afford, and it slowly grew upward and increased its applicable market segments until it, now, is the high end of the marketplace.

ARM is now potentially in a similar situation. And like the x86 before it, it has tremendous inertia in the smartphone platform, any of which are easily capable enough to operate as a PC for most uses for most people. It uses something less than 1/100th the power of my laptop and is a reasonable, convenient stand-in for said laptop for pretty much all personal use other than for my work. (I'm a software engineer)

I've already started to note the conflict: do stuff on the phone or the laptop? So far, it's mostly worked because stuff I do on the phone is pretty much "in the cloud" and is accessible from the PC.

But Pictures? I've taken a few hundred pictures, and keeping them in synch starts to become a hassle...

At some point, it could make sense to jump, to switch from one to the other. Why couldn't my phone have a plug or a bluetooth connection to a keyboard, monitor, etc?

Re:Sparc

[PCM2]

It is saddled with decades of backwards compatibility issues as well, 16-bit modes, segmentation, IO ports, and other things that no one uses anymore if they can help it.

Actually, Google Native Client (NaCl) uses segmentation to sandbox downloaded code. It's either a brutal hack or a totally clever trick, I guess, depending on your POV.

Re:Sparc

[Waffle Iron]

Internally the modern x86 is really a RISC at heart anyway. But it's got a really massive support system on top of that that converts the older style CISC instruction set into a VLIW/ RISC style that's more efficiently executed in a superscalar way.

If you look at a picture of any modern CPU die, the real estate is totally dominated by the caches. That "massive support system" (which in reality is only a tiny fraction of the whole die area) serves largely as a decoder that unpacks the compact CISC-style opcodes (many of which are only one or two bytes long) into whatever obscure internal superscalar architecture is in vogue this year. This saves huge amounts of instruction cache space compared to unpacking bloated one-size-fits-all RISC-style opcodes into the some similar internal architecture du jour. Thus, the X86 can end up needing less die area overall. This is one reason that despite what elitists geeks say, over the years X86 has usually provided more bang for the buck than any competing processor family.

This scheme is so advantageous, that even ARM has tacked on a similarly convoluted opcode decompresser. If ARM ever evolves into a mainstream general-purpose high-end CPU, there will be undoubtedly dozens more layers of cruft added to the ARM architecture to make it competitive with X86, at which point it will be similarly complex. (For another example, take a look at how the POWER architecture ended up over time. You can hardly call it RISC any more.)

Re:Sparc

[TheRaven64]

Since this is an article about Itanium, it's worth noting that Itanium copies the predicated instruction model from ARM. This doesn't just make the code denser, it meant that ARM could get away without having a branch predictor for a very long time (new ARM chips have one). It works very nicely with superscalar architectures, because the instructions are always executed, and the results are only retired if the condition is met. You always know the state of the condition flag by the time the predicated instructions emerge from the pipeline, so it's trivial to implement in comparison with the kind of speculative execution required for predicted branches on x86.

Lots of people seem to assume that x86 is translated into RISC and then x86 has no impact on the rest of the execution pipeline. This is absolutely not the case. The x86 instruction set is horrible. Lots of things have side effects like setting condition registers, which cause complex interactions between instructions in a pipelined implementation, and insanely complex interactions in an out-of-order design. This complexity all has to be replicated in the micro-ops. Something like Xeon then has a pass that tries to simplify the micro-ops. You effectively have an optimising JIT, implemented in hardware, which does things like transforming operations that generate side effects into ones that don't if the relevant condition flags are guaranteed to be replaced by something else before they are accessed. All of this adds to complexity and adds to the power requirement.

Oh, and some of these interactions are not even intentional. Some of the old Intel guys tell a story about the first test simulations of the Pentium. It implemented all of the documented logic, but then they found that most of the games that they tried running on it failed. On the 486, one of the instructions was accidentally setting a condition flag due to a bug in the design. Game designers found that they could shorten some instruction sequences by taking advantage of this. In the Pentium, they didn't recreate this bug, and software broke. After the first phase of testing, they had to go back and recreate it (adding some horrible hacks in the Pentium design in the process), because if games suddenly crashed when people upgraded to a Pentium then people would blame Intel (Windows 95 had a hacky work-around to prevent SimCity crashing on a use-after-free bug, for the same reason). All of these things add to complexity and in hardware complexity equals power consumption.

Or if, you are that way inclined, you could argue about Java/.NET bytecode making code compiled at run time achieving the same thing.

And, if you are, then Thumb-2EE is a much nicer target than x86 for running this code. It has instructions for things like bounds-checked array access, which really help performance in JIT'd VM code.

The processor that sunk HP's UNIX line

[AtariDatacenter]

I still remember the day the HP sales/technical team came on-site to give us a presentation. Flashy videos with Carly Fiorina's new vision of the future. And a bright tomorrow with a new CPU line... out with PA-RISC and in with Itanic. Their sales team looked at each other nervously as we expressed our evaluation of the arrangement as a failed vision. It didn't take them long to figure out that dumping their in-house CPU to go with the Itanic would doom them to irrelevancy. And it did.

Now the Itanium itself is sinking from irrelevancy. It took too long. This chip was a disaster. Glad to see it go.

Re:The processor that sunk HP's UNIX line

[yuhong]

Yep, I think HP is the main customer for Itanium nowadays. Windows is going to drop support after Server 2008 R2 (support was limited in Server 2008 to certain parts). Red Hat dropped support for it with RHEL6.

Re:The processor that sunk HP's UNIX line

[Third Position]

You have to wonder what chip architecture HP is going to move to now, considering losing Itanium leaves them high and dry. Of course, Itanium was largely developed by HP. Perhaps HP will continue the processor line?

It certainly isn't going to do HP any good having to do another architecture switch. To this day, most of the HPUX servers in my shop are PA-RISC. Moving to Itanium has generally been painful enough that when our development teams are forced to upgrade their applications, they generally opt to rehost them on Linux on x86 rather than HPUX on Itanium. Only a few applications where that isn't adequate have made it to HPUX Itanium. Putting their customers through another painful transition isn't going to win HPUX any friends.

Re:The processor that sunk HP's UNIX line

[Mysticalfruit]

I've long argued that Itanium was Intel's vehicle to kill PA-RISC and get HP out of the high performance computing market and it worked. Intel let that CPU die a death of a thousand committee compromises while simultaneously plundering all of the technology they could out of Alpha and rolling out their Xeon cpus out at much higher clock speeds and with features that weren't in Itanium.

I worked at a computer company and we built servers that used PA-RISC cpus at the time and we got our hands on some Itanium samples and needless to say, we decided to migrate the platform to Xeon instead.

Re:The processor that sunk HP's UNIX line

[Apotsy]

Not that I'm a big fan of Carly, but you can't necessarily blame her for that. The decision for HP to go with Intel's fancy new solution was made in era of Lew Platt being CEO, well before Fiorina took over. I was at HP in the mid-90s and recall seeing roadmaps that showed HP's UNIX solutions all being based on the super-amazing upcoming new Intel architecture well before the end of the decade. PA-RISC was old and busted, and Intel had the new hotness just around the corner. The suits just couldn't say enough about what an unstoppable juggernaut Intel's new baby was going to be. According to them, it was going to solve everything, do everything, and pretty much take over the world.

I left in 97, but I am sure those roadmaps had to be quietly adjusted each time Intel's new chip was delayed (over and over). It was well past 2000 when the thing finally came out, and in the end, it was a huge disappointment (dare I say disaster) after PA-RISC had been sailing along smoothly for so long. The perf was terrible, the instruction set was a mess, and pretty much the entire industry did their best to avoid it. I'm surprised it took this long for Intel to throw in the towel on it.

PA-RISC really was a great series of CPUs. It's a shame it had to die. At one point I believe it actually surpassed the (at the time) much-vaunted DEC Alpha as the fastest thing on the market, if only for a little while. Itanium seemed designed solely to kill off the x86 CPU clone market. Intel came up with a completely new instruction set, and patented it so there would be no clones. Actually making a good chip did not seem to be a consideration.

Good riddance to Itanium, and a bittersweet farewell and R.I.P. to PA-RISC.

Re:The processor that sunk HP's UNIX line

[Apotsy]

Oh and I have to mention that HP's decision wasn't necessarily a bad one given the trends that were happening in the mid-to-late 1990s. The big story in everyone's minds was that expensive UNIX workstations were on the way out, to be replaced almost overnight by cheap commodity PCs running WindowsNT (don't laugh, it was the first "Windows" to be taken seriously). SGI pretty much lost their entire hardware business that way. HP was just trying to save themselves from that fate by hitching their future to what looked to be the industry's dominant player.

Ah well

[Mr Z]

I work directly with a VLIW architecture myself (the TI C6000 family of DSPs). From that perspective, I'm a little sad to see Itanium go. I realize EPIC isn't exactly VLIW, but they had an awful lot in common. Much of HP's and Intel's compiler research helps us other VLIW folks too.

I think EPIC tried to live up to its name a little too much. The original Merced overreached, and so it ended up shipping far too late for its performance to be compelling. Everybody always zooms in on the lackluster x86 performance, but x86 wasn't at all interesting in the spaces Itanium wanted to play in originally. It wanted to go after the markets dominated by non-x86 architectures such as Alpha, PA-RISC, MIPS and SPARC. And had it come out about 3 years earlier, it may've had a chance there by thinning the field and consolidating the high-end server space behind EPIC.

Instead, it launched late as a room-heating yawner. And putting crappy x86 emulation on board only tempted comparisons to the native x86 line. That it made it all the way to Poulson is rather impressive, but smells more like contractual obligation than anything else.

Rest in peace, Itanium.

Re:Can't blame them

[SpazmodeusG]

What are you talking about? The early Itaniums were x86-32 compatible.
"Itanium processors released prior to 2006 had hardware support for the IA-32 architecture to permit support for legacy server applications"

http://en.wikipedia.org/wiki/Itanium#Architectural_changes

It wasn't until later the Itaniums lost their hardware based x86 compatibility.

Ya HP is calling bullshit too

[Sycraft-fu]

http://www.businessweek.com/news/2011-03-23/hp-calls-oracle-move-shameless-gambit-to-hurt-competition.html

I'm much more inclined to believe Intel and HP on it. While the Itanium did not become the be-all, end-all for computers Intel hoped (they wanted to go to it because their cross licensing is for x86, not IA-64) it has not been a failure. People like to joke about it and rag on it but all it means is they've done little to no research. It is a competitive chip in the super high end market. When you need massive DB servers or the like, it is a real option and one that people use.

Now as to what kind of future it'll have I can't say. The high end segment keeps shrinking as normal desktop hardware gets better and better. You can knock 4 8-core Xeons in a system right now and get some great performance at a good (relatively speaking) price.

At any rate I wouldn't listen to anything Oracle says, particularly about competitors. They are not known for their truthfulness, or for their sense of fair play.

Why not post intel's response?

[sitkill]

Not sure why the submitter didn't post the Intel response denying it: http://newsroom.intel.com/community/intel_newsroom/blog/2011/03/23/chip-shot-intel-reaffirms-commitment-to-itanium While you would think Intel would of course deny it, but considering Intel just took the wraps off their next revision of the Itanium, this is pretty much just FUD coming from Oracle.

It's just ARM heads

[Sycraft-fu]

Comes from the general geek thing of liking the underdog (though one has to ask how underdog they really are given their mass marketshare in embedded devices) and from hating CISC. A lot of geeks take CS classes and learn a bit about processor theory, but not any of the CE/EE to understand the lower levels and thus decide CISC = bad RISC = good.

What it all adds up to is they hate on Intel and love ARM, and want to see ARM in the desktop space.

As you said, I've yet to see anything showing ARM is faster than Intel in an equal setting. Yes, a Core i7 uses a lot of power. However it does a lot. Not only is it fast at the sort of operations ARM does, it does other things as well. Like 64-bit. You think ARM isn't doing that just because they are jerks? No, it is because 64-bit needs more silicon, and thus more power. How about heavy hitting vector units? Same deal.

ARM is great for what it does but those who think that it is some amazing x86 replacement just haven't done any looking. Turns out Intel is pretty much the best there ever was when it comes to getting a lot out of silicon. They produce some powerful chips. Could ARM design one as powerful? Maybe, but guess what? It wouldn't be a tiny fraction of a watt deal anymore. It'd be as big and power hungry as Intel's offerings.

You can see this from other companies as well. If x86 really was the problem, and another architecture could do so much more with less, then why doesn't anyone else do it? Remember IBM, Hitchai, Sun, they all made non-x86 chips. Yet none of them are killing Intel in terms of performance for watts. IBMs POWER chips are a great example. They have an apt name: They are fast as hell, and draw a ton of energy. They really are for high end servers (which is what IBM designed them for). Despite being RISC based (though you find desktop/server RISC chips are quite complex both in terms of number of instructions and capability) they are not some amazing low power monsters that can rip x86 apart. They are fast, powerful, high end chips that take a lot of silicon and a lot of juice to do what they do. Go have a look at the massive heatsink for a POWER5 chip on Wikipedia.

Different chips, different markets.

Re:It's just ARM heads

[jabjoe]

My money on 'why' is Windows compatibility and closed source locking the platform more than chip design. The best design doesn't always win, in fact, it often doesn't. This was because of Windows going critical mass and with it x86. So much money was poured into x86 you just got more for your money with x86, and the more that was the case, the more sold, and the more it was the case. This meant it came into the server market from the bottom, and then the same happened there. It's a good example of a bottom up revolution. Now it looks like Wintel compatibility doesn't matter so much (web/freesoftware), and something similar could happen with ARM driven by them being "good enough", cheap and low power. That's why Intel are pooing their pants and MS are hedging their bets with Windows on ARM.

Re:as a former Itanium employee

[BLToday]

My old college roommate was offered a job at Intel Itanium's unit after finishing his PhD in compiler theory. He turned it down because "life's too short to spend it fixing Itanium."

Re:...and?

[bhtooefr]

It's a FUD attack at HP, Oracle's newest enemy, FWIW.

(HP is the only company that really uses Itanium any more.)