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

[JanneM]

On the low-power mobile and embedded side x86 is out. Never mind power-performance - absolute power levels is what matters most. And the big volume in cpus is in this market, from smartphones on the upper end down to windshield wiper controllers and stuff like that on the low end.

On the very, very high end, again, there's good reason not to use x86, and instead do something like Hitatchis Sparc-based cpus. You have basically low or no concern for binary compatibility - you're most likely running a custom-rolled linux and building all your applications from source or from scratch.

You need things like on-chip support for specialized high-speed interconnects, and power-performance as well as absolute power consumption becomes hugely important when you're trying to cram half a million cores into one single building.

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

[Anonymous Coward]

download specbench, build and enjoy. a single p7 core running a single thread is fucking assloads faster than a nehalem core (and that's _without_ heavy FP or decimal).

for extra laughs, watch how the gap grows to nearly 2x by moving to GCC on the POWER7 and xeon system.

"i do this for a living" - is that you, demerjian?

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

[Sj0]

This story is about the further decay of Intel's once flagship product, the Merced. If anything, this story shows that x86 and extensions of it DO have a very important place in the market. Despite having existed forever before x86-64, it wasn't until the Opteron and Athlon 64 that 64-bit architecture became commonplace. It wasn't Merced, it wasn't DEC Alpha, it wasn't a Motorola processor.

Ignoring the practical reasons why x86 continues to survive may make sense in a vacuum of academic computer science, but even academic engineers should be looking at the realities of the situation.

Re:Sparc

[afabbro]

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.

That's a really silly analysis. Oracle could not care less about HP-UX because they don't compete in the proprietary Unix market. No one does. Yes, Oracle owns Solaris, but Ellison's smart enough to know that proprietary Unices only exist to sell the servers attached to them. There's no money in selling proprietary Unix operating systems by themselves.

Now that PA-RISC is gone, the only thing HP-UX runs on it Itanium. Already, you can't run any Microsoft or Red Hat on Itanium. And those are just companies that previously supported it - tons of companies simply never did. With Oracle out of the picture, Itanium is effectively dead. Yes, you can continue to run your in-house and specialty apps on it, but Oracle has a huuuuge presence in enterprise software, way beyond just databases.

I expect other remaining vendors to jump in - they have no love for supporting a operating system with a low market share.

HP is stuck and will either port HP-UX to x86 or migrate customers to Linux on x86.

Re:Sparc

[Darinbob]

the ARM thumb decompressor isn't that convoluted. And it has fixed length 16-bit words like most RISC machines (even the 16-bit version of MIPS does the same). It means it has a nice simple fetch cycle. If you have no cache (as in smaller ARM versions) then it's one instruction fetch per two instructions. Thumb mode basically is a tradeoff of space for performance; you end up executing more instructions overall.

Re:Sparc

[jabjoe]

ARM is more compact that a normal RISC architecture because most instructions are conditional and can have bit shift or rotations too. This doesn't just mean less instructions required to do common tasks, but it also means less branching, which isn't only faster, but again leads to less instructions as 'branches' can share instructions. In the old Acorn days I remember how much noise there was about how much more compact it was than x86. ARM isn't the RISC your daddy knew. Thumb just makes it even more compact, and unlike x86's instruction decoders, it can be powered off and not used.

x86 really problem is legacy. It has to be backwards compatible, ARM doesn't bother. You might says that's terrible, and people do, but they aren't thinking open source, where the repository can be just compiled for the different target as needed. The user doesn't need to know or care, they just do apt-get regardless. Or if, you are that way inclined, you could argue about Java/.NET bytecode making code compiled at run time achieving the same thing. Either way, you can free up the chip design from legacy.

Re:Sparc

[TheRaven64]

In that case, it won't work on x86-64, because segmentation doesn't work in 64-bit mode. Xen also uses segmentation, so the hypervisor and guest can share a linear address space and not need a TLB flush on hypercalls.

Segmentation is actually really nice, but the x86 implementation sucks. You have a two segment tables. The GDT is shared between all processes, the LDT is per process (TLB flush required to change it, next few dozen memory accesses will be very slow). Each contains 8192 entries. For an OO system, it would be fantastic if you could use segment IDs as object IDs. You'd get automatic range checking on every object. Garbage collection would be easier, because you wouldn't have interior pointers, you'd always access fields with segment-offset pairs, and you could even relocate objects in linear memory for heap compaction. Except, on x86, you'd be limited to about 8190 objects (you also need one segment for the stack and one for code, at the very least). Oh, and you need a TLB flush for every new / free.

Somewhat depressingly, the iAPX had a much nicer segmentation system, and shipped (from Intel!) several years earlier than the 386 (which introduced the current protected mode segmentation system, which is an ugly hack so that you can make real mode assembly work with a specific layout of LDT entries).

Re:Sparc

[TheRaven64]

Check the architecture reference for the ARM11. The Thumb decoder on ARM11 translated Thumb instructions into ARM instructions. With the Cortex A8 and newer chips, there are two separate decoders, one for ARM one for Thumb-2 (and Thumb-2EE). When you're in Thumb-2 mode, the ARM decoder is powered down. When you're in ARM mode, the Thumb-2 decoder is powered down. This is responsible for a big chunk of the power savings from ARM11 to Cortex A8.

On an x86 chip, the micro-op decoder is about as complex as the ARM or Thumb-2 decoder. Xeon saves some power by caching small sequences of micro-ops and then powering down the x86 decoder (works well in tight loops), which gets the decoder power load close to that of ARM.

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.

that's still around?

[Ultra64]

I didn't realize the Itanium was still being produced. I thought they shut it down years ago.

Re:Marketing Coup

[Guy Harris]

Good thing that they managed to change the new architecture from "AMD64" to "x64".

That would be bad if customers thought that AMD out-innovated them.

Actually, I think AMD originally called it x86-64, and then their marketing department got them to call it AMD64 (not a bad idea, from the marketing point of view). Sun and Microsoft decided to call it "x64", probably after Intel licensed it, perhaps so as not to peeve Intel. Intel thrashed around a bit with names, passing through EM64T before arriving at the innovative name "Intel 64", which does not at all resemble "AMD64".

(Not that Intel invented PA-EPIC^WIA-64^WItanium all by themselves, either.)

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.

Re:The processor that sunk HP's UNIX line

[ppanon]

Yes, if you saw Intel roadmaps from the late 90's, that was exactly Intel's plan. They opened the door with Itanium and AMD walked through it with Opteron. They also opened another door earlier when they were pushing P4/NetBurst/RAMBUS which let through Thunderbird. They've been a little more careful about trying non-competitive gouging manoeuvres since, but there is little reason to believe they wouldn't go back to those tactics if AMD went under tomorrow.

Re:Can't blame them

[ShakaUVM]

>>On top of that Intel only sold Itaniums to enterprise, screeching compiler development for it to a hault.

I had experience working with the preproduction Intel compilers for it, and it was very, very good.

One of the best things about the platform, really. Kind of like the Tera.

Re:Can't blame them

[the linux geek]

Uh, you realize SPARC, Power, z, Unisys BLS, Unisys Dorado, and all the other enterprise platforms lack x86 compatibility too, right?

Itanium has its failings. That isn't one. Those who talk about how that is the problem aren't the people that Itanium is for.

Re:Is Larry's foot sore yet?

[stevel]

... and VMS .. and NonStop. Both systems with a lot of customers that find lots of value in those platforms and don't want to give them up.

Re:Is Larry's foot sore yet?

[the linux geek]

It's also used for VMS, HP NonStop, and some proprietary systems (GCOS, ACOS). NonStop is probably tougher to move away from than HP-UX.

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.

Sink It?

[bloodhawk]

To Sink it, doesn't that imply that at some time it actually floated. That processor line has had all the floating abilities of your average house brick since launch, sure for a while a few companies tried to fit the brick with lifejackets, but in the end they were always destined to sink to the murky depths of hell.

Oracle Had a Lot of Itanium Software

[BBCWatcher]

HP has very little software to offer, so with major software vendors (Microsoft, Red Hat, and now Oracle) fleeing Itanium, it certainly isn't good news for HP. Oracle Database is probably the most popular software product running on HP-UX, as a matter of fact, but Oracle's announcement represents the end of the line. Oracle has a lot of other significant products, too, like Tuxedo, WebLogic Application Server, and Siebel, among others. Ironically IBM may now be the biggest vendor of Itanium-compatible software. Of course this Oracle announcement is self-serving, but it's also brutally smart business strategy. Itanium really is dead as a doorstop without popular software. This move also kills HP's aspirations of overtaking IBM any time soon, and it also kills one of HP's more profitable business lines. (Well played, Larry.)

Re:Oracle Had a Lot of Itanium Software

[durdur]

> This move also kills HP's aspirations of overtaking IBM any time soon

Exactly - HP nowadays really wants to be IBM, a one-stop shop for hardware, software, and services. But they're not. IBM has a better mix of businesses and is executing better. HPQ operating margin - 10.49%, IBM operating margin - 19.97%. HPQ return on equity - 21.85%, IBM return on equity - 64.59% (from Yahoo finance).

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.

Re:Can't blame them

[Mad Merlin]

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.

While true, you omitted the crucial continuation of that sentence:

Itanium processors released prior to 2006 had hardware support for the IA-32 architecture to permit support for legacy server applications, but performance for IA-32 code was much worse than for native code and also worse than the performance of contemporaneous x86 processors.

Re:...and?

[Anonymous Coward]

I'm not surprised at the bias, poorly researched article that was published once again. Intel specifically said that they have no plans on dumping it and that Oracle is full of shit. The headline is like an attack at intel even though intel did nothing besides deny what oracle said.

Re:Commercial software for Itanium?

[rubycodez]

I work for HP VAR, that's the main use of our clients HP/UX and Itanium LInux boxes, to run Oracle software. A few even ran Windows for Itanium for SQL server, some ran BEA Weblogic. If IBM throughs Websphere for Itanium HP/UX under the bus, then that's all she wrote.

Itanium, from the same people that brought the P4

[BlueCoder]

In all truthfulness it did have some ideas going for it but it should have stayed a pet project. An R&D project but produce enough that the market could play with it in self built systems. In my opinion they should have basically given the processors away to inspire developers for hobby and niche products. They wouldn't have lost as much money and would have had more realistic ambitions for it. They had the fabs and the prototyping equipment already...

The Itanium, a processor designed for programming languages that could provide optimization hints... that could have a concept of L1 cache and manipulate it and be able to provide feedback to the processor when it could do better branch prediction than the processor. Radical concept, only problem was you HAVE TO code to each processor model specifically. Caches changed and the processor logic changed with each revision. That's why they would have made better embedded processors. The generic systems that would benefit the most would be systems with source code you could compile right for the machine, and dynamically compiled code, and code that could self compile and optimize itself.

They should have been much more radical instead and designed for massively parallel systems based on a RISC design with minimal branch prediction. So even if the processors weren't running the more efficient code a developer could at least attack a problem with the brute force of hundreds of threads at the same time. More or less they should have aimed for something along the lines of the cell processor. Another current story here on Slashdot is how how the US Air Force took 1700 PS3's and turned them into a computer that qualifies in the top 40 for supercomputers.

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:It's just ARM heads

[hairyfeet]

But nobody ever asks the important questions, such as : Why did Windows win (hint: It is NOT a conspiracy)? Why hasn't everyone ditched their desktops for Linux on ARM? Hell why hasn't Linux on x86 gotten more than the margin for error even though it has been free for 15 years?

I'll tell you why, and it'll be the same reason why Windows on x86 will ultimately win against ARM on the desktop: elitism. Before WinNT server OSes were a CLI heavy, having to know shitloads of arcane commands good old boys club where only the "true" admins were allowed to play and that is how they liked it. Linux today has that same problem, anything that makes it easier for the user automatically gets accused of "dumbing down" for the "noobs". Hell some of the developers are so anti-user I'm shocked they don't have the pic of Johnny Cash flipping the bird as a loading screen before dropping you into a shell and demanding all code in brainfuck.

But Windows came along where "lets be friendly for users!" was a mantra and where any middle manager could set up file and print serving and totally changed the game because they took away a LOT of frustration. Hell I could teach my 15 year old how to run a basic Windows domain in less than two weeks easy.

Another example of user hostility and elitism is in this very thread where so many are screaming about how backwards compatibility is bad and evil, well you know what? For the users of the world allow me to say "go fuck yourselves, because we don't care what you think developers!" That's right, we LIKE backwards compatibility! My mom LIKES being able to play her AoE I and ancient match 3 games on her new PC, I LIKE being able to run all my old games and programs, I LIKE being able to stick with Office 2K even on my new x64 quad running Win 7.

The developers here seem to forget we the users are the ones buying the hardware and while developers may not give a shit or have anything invested in their software (hell as long as they have an IDE and a compilers they're happy) we the users have time, money, and experience invested in our programs and we do NOT care whether you think our shit isn't cool anymore we LIKE it and we WILL keep it!

So I would say the whole ARM VS x86 debate is just a microcosm of the whole developers VS users debate, and I'm betting once again the users win over the developers. Not everyone (in fact I would say damned few) want to get on the Apple "toss every couple of years" treadmill when it comes to their work and play programs. ARM can get away with that shit in its current niche because cell phones and pads are considered disposable items by the users and they frankly don't have shit invested in them. Like their cell they just toss and get another one, and never expect any of their programs to work.

The reason ARM (and Linux) is doomed to fail on the desktop is people DO expect to be able to keep their programs and with both unless you have compiling skills (which knocks out a good 85% of the public) you WILL take the new hotness or be SOL, because the developers only care about the new hotness NOT whether or not they break everything that came before it. But the public simply won't go along with that on the desktop thanks to Windows showing them programs CAN be run year after year, OS after OS, and it'll all "just work" for the most part.

To me it all smacks of developer elitism, and that way lost before and WILL lose again. The public simply won't go along.

as a former Itanium employee

[Anonymous Coward]

I agree with Oracle that it is close to over for the chip. Intel lost every good engineer working on it to AMD in Fort Collins, CO and can't (even with massive financial incentives) coax anybody on their x86 teams to transfer over. Itanium is considered the kiss of death on a resume so they are having a hard time even finding people willing to work on it. Work on Itanium is about 6 years behind original schedules! Originally designed and marketed as a performance leader to the Xeon series it has fallen so far behind that it had to be re-marketed with FUD about quality, scalability, and stability. While I agree it has better quality and stability than the i3,5,7 series, Intel has a hard time explaining how it is better in those terms compared to their higher end Xeon series.

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.)