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

...and?

[betterunixthanunix]

Is anyone actually surprised by this?

Re:...and?

[Low Ranked Craig]

I thought it went the way of the DEC Alpha long ago

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

Re:...and?

[TheRaven64]

Absolutely not. The Alpha remained on the top 100 supercomputers list for a decade after they stopped designing new ones. It died only because Compaq bought into the Itanium hype and killed it. Itanium died by virtue of Intel completely failing to learn from history. They followed exactly the same development model for Itanium that gave them run-away successes like the iAPX and i860 CPUs.

If Intel kills Itanium, the only people who are likely to care are VMS users. HP supports OpenVMS on three platforms: VAX, Alpha, and Itanium, and only sells new versions for Itanium and does not appear to have plans to provide it for any other architecture. Somewhat ironically, the four-ring protection model in x86 (which was dropped in x86-64) was created specifically to make porting VMS to x86 easy. Looks like a good time for IBM to start offering a VMS compatibility layer to z/OS...

Re:...and?

[TheRaven64]

HP is the only company that really uses Itanium any more

And HP adopted Itanium because management decided that having a CPU architecture that was only used by one company was too expensive...

Re:...and?

[Sique]

Actually, Itanium is a successor to the HP PA RISC architecture and borrows from there.

Re:...and?

[VolciMaster]

And don't forget HP-UX users, and overseas companies like Fujitsu.

Re:...and?

[ibsteve2u]

That is a tragic story...both DEC's (oh, sorry...that sorry Compaq's) Alpha and SGI's MIPS processors were killed off by corporate decisions to run in fear from what turned out to essentially be vaporware.

As someone who has an affection for VMS - albeit I haven't touched it in a decade - I still get ticked off when I recall what the CEO breed did to DEC and their hardware.

Their stuff worked...and the ability to control users and running images with such granularity...sigh...the original "Set it, and forget it.".

So of course DEC had to die.

Sparc

[Gary Franczyk]

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

Re:Sparc

[Patch86]

And they managed to get in a good, FUDdy parting shot on their way out (lovely chaps, those folks at Oracle).

Unless of course they're telling the truth. Which would be a shame, if not a surprise. Itanium deserved at least slightly better a life than it go (and Intel, once burned, may never try moving away from i86 again, god help us).

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]

and Intel, once burned, may never try moving away from i86 again

The market will move Intel. Intel didn't create x86_64. Intel is looking over its shoulder at ARM right now. The fate of computing doesn't rest with Intel. It never has.

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

[Anonymous Coward]

You realize Power7 is ~80% faster than Intel's highest-performing server processor (Nehalem-EX), right?

Re:Sparc

[the linux geek]

Intel is obligated to continue developing Itanium, or HP sues them. Itanium isn't going anywhere, and Oracle is spreading FUD.

Re:Sparc

[ArhcAngel]

Or maybe Intel is more worried about the new ARMs race.

Re:Sparc

[Anonymous Coward]

and more than 5 times as expensive.

Re:Sparc

[camperdave]

There's an old saw that goes "Lead, Follow, or Get Out of the Way". If you're looking over your shoulder, you're in the way.

Re:Sparc

[rahvin112]

And you can buy 7 of the Intel processor systems for the price of a single Power7 system. A slight performance advantage for a single generation doesn't do you a damn bit of good when Intel is tick-tocking every 2 years while power refreshes every 5 and Intel is at least 1 process tech ahead of everyone else including IBM. In 6 months to a year the Intel processor will catch up and then exceed the Power, 5 years later IBM will leap ahead again. That is providing the trend keeps up and IBM doesn't abandon power entirely further down the road.

Architecture is irrelevant, the modern x86 isn't even x86 anymore except for the 2% of chip real estate devoted to decoding the incoming instructions and dispatching them to the internal architecture. That's all x86 is these days, a bloody abstraction layer.

Re:Sparc

[Anonymous Coward]

Yes, yes. Itanium's not dead, it's just pining for the fiords.

Re:Sparc

[Anonymous Coward]

You forgot to factor in the cost of datacenter-grade HVAC and redundant power. Those intel boxes will use a lot more power and create a lot more heat to get the same job done. Now, if you're talking about the Atom, all bets are off, but it better be an "embarrasingly parallel" problem.

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

[jd]

Immaterial. The x86 is a lousy architecture and adding onto it hasn't helped any.

Intel's latest stuff is certainly not the best that ever was. It has no support for content-addressable memory and no support for MIMD, it isn't asynchronous, it's not 128-bit, it doesn't use wafer-scale integration, it doesn't support HyperTransport (which is faster than PCI Express) and it can't do on-the-fly instruction set translation --- all these things have been done on other architectures, making those architectures superior in these respects to Intel's latest and greatest. Even though some of these things were being done by others when Intel's best offering was the 8080.

IBM's POWER7 not only comes close, it beats the crap out of the Intel clone of the AMD x64 design. Yes, Intel were forced to clone AMD's design because theirs stank.

As for "ever has", the IIT 8087 was two orders of magnitude faster than Intel's. The 64000 was not only better than the 8086, it was a LOT better. The Transputer was 32-bit and could scale to the thousands of cores in a single box when Intel was 16-bit with an absolute limit of one core on one CPU.

In fact, I would be willing to bet that a 16-way Intel box with the latest CPUs could still be beat in raw processing power AND addressable memory space by a hypercube of Inmos T400s dating to 1984. THAT was "the best stuff that ever was" and I challenge you to show me a single thing Intel can do better now than Inmos could do then.

Re:Sparc

[sunderland56]

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

Oracle develops and sells both Solaris and their database software for x86 platforms, which they do not own.

I think it is more the fact that (a) they *never* had a version of Solaris for Itaniium; and (b) with both RHEL and HP-UX dropping support for Itanium, they would have no platform to run their databases on.

Re:Sparc

[c0lo]

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

Yeap. But, in the context of the Oracle behemoth database server, does mobile processors have any relevance? It seems that it does - even if an ARM-based server is no longer what one would call "mobile".

One on top of the other, may it be that the Itanium heavyweight approach is indeed a dinosaur of the past?

Re:Sparc

[Anonymous Coward]

You realize Power7 is ~80% faster than Intel's highest-performing server processor (Nehalem-EX), right?

Where do you get this from? A single p7 core running a single thread is not faster than a Nehalem core. I do this for a living, trust me.

Re:Sparc

[c0lo]

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.

Why do you think ARM is equivalent with less computation power? Maybe it is so for the present, but doesn't seem so for the near future

Re:Sparc

[c0lo]

Intel is obligated to continue developing Itanium, or HP sues them. Itanium is going nowhere, and Oracle is spreading FUD.

FTFY. Other than that, all your other assertions ring true to me.

Re:Sparc

[Anonymous Coward]

Immaterial. The x86 is a lousy architecture and adding onto it hasn't helped any.

Intel's latest stuff is certainly not the best that ever was. It has no support for content-addressable memory and no support for MIMD, it isn't asynchronous, it's not 128-bit, it doesn't use wafer-scale integration, it doesn't support HyperTransport (which is faster than PCI Express) and it can't do on-the-fly instruction set translation --- all these things have been done on other architectures,

i call logic error. just because all of these have been done on
some arch, doesn't mean all of these have been done on any
arch, nor does it mean even one of these are worth doing. 128
bit? why? do you own stock in hynix?

IBM's POWER7 not only comes close, it beats the crap out of the Intel clone of the AMD x64 design. Yes, Intel were forced to clone AMD's design because theirs stank.

and yet qpi has advanced to the point were it is more interesting than
hypertransport. intel may not have been first, but they understood what
amd was doing, and executed better.

As for "ever has", the IIT 8087 was two orders of magnitude faster than Intel's. The 64000 was not only better than the 8086, it was a LOT better. The Transputer was 32-bit and could scale to the thousands of cores in a single box when Intel was 16-bit with an absolute limit of one core on one CPU.

In fact, I would be willing to bet that a 16-way Intel box with the latest CPUs could still be beat in raw processing power AND addressable memory space by a hypercube of Inmos T400s dating to 1984. THAT was "the best stuff that ever was" and I challenge you to show me a single thing Intel can do better now than Inmos could do then.

now you're clearly batshit insane.

Re:Sparc

[zaphirplane]

I don't have the knowledge to have an opinion on what's being discussed

your power refreshes every 5 years sounded wrong, I double checked and ...
http://en.wikipedia.org/wiki/POWER6 power6 released 2007
http://en.wikipedia.org/wiki/POWER7 power7 released 2010

why do make up facts ? really I am interested

Re:Sparc

[zaphirplane]

.....
  and HP-UX dropping support for Itanium

really? what's hp-ux going to run on?

Re:Sparc

[Anonymous Coward]

You think HP would jump on over to IBM, AMD, or ARM processors and wait for its settlement check while tanking in the server market? HP has nowhere else to go.. they would continue doing business with Intel in all segments (desktops, workstations, servers, ...)

The only question is what the relative costs are:

a) continue developing itanic for $x payable in todays dollars
b) settle a contract dispute for $y payable in tomorrows dollars

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

[Anonymous Coward]

Why do you think ARM is equivalent with less computation power? Maybe it is so for the present

That word is; Based on your comment I don't think you fully appreciate its meaning.

Re:Sparc

[Anonymous Coward]

screw that, I obstruct

Re:Sparc

[c0lo]

Quoting the GGP post

I wouldn't want to do my day to day desktop computing on it.

If that word must be interpreted stricto sensu, can you please point to me where can one find now a desktop computer powered by ARM? I would fully appreciate the reference, thank you.

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

[Funk_dat69]

That's kind of a weird comparison, though. Power7 cores have 4 hw threads. Nehalem has 2 'hyper' threads.

Like any tool, you pick the right one for the job. Nahalem is quite fast on a single thread, but if you have a web server processing boat loads of transactions/second, you may look towards a tool that is fast on many theads and can churn through many transactions concurrently.

Re:Sparc

[syousef]

Intel is obligated to continue developing Itanium, or HP sues them. Itanium isn't going anywhere, and Oracle is spreading FUD.

Really? Do you think someone using an Oracle database on IA-64 is going to convert to a different DB? I don't think so.

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

[Sj0]

I think you've got a false dichotomy here.

It's highly HIGHLY unlikely that x86 is going to be usurped by anything any time soon. Part of the reason is, despite apparently every person here's hatred of it, the legacy of x86.

There's always going to be that one application that you just can't find a replacement for. Even among FOSS software, there's a good chunk that is non-trivial to port to a non-x86 architecture. This is fine in sectors like smart phones, where the segment isn't so bogged down in legacy applications that you can just drop everything and start with a brand new OS and a brand new CPU every couple years, but in the PC market, and even in the Server market, that's just not going to fly. Give the smart phone market 5 years, and we'll see a lot of the same legacy there, if any of the current platforms stabilize that long.

The other reason is political: x86 is a once in a million event of an open-ended architecture actually took over the market. Existing non-x86 markets show us what we can look forward to if the platform were to ever die. Want to install linux? Get ready to either hack your computer(If you're lucky and find a hole in the security) or to beg the manufacturer to give you the option. Peripherals for a proprietary solution will always cost more because there will be less competition because of higher barriers for entry. The actual machines themselves will cost more for the same reason. Most industries aren't about to lose that flexibility for an appliance controlled by another company. The whole PC platform may seem like the wild west, but even Android can seem like North Korea at times(Watching people praying for a new version of Android to come to their phones despite the ability to compile from source is a great example of this).

What we're seeing instead is the opposite. Rather than seeing ARM et. al. taking over the ultra low end PC market(despite plenty of attempts to over the years), it was the Intel Atom that effectively created the segment for the first time.

That said, there's no reason why ARM et. al. can't exist in the completely different segment of highly locked down appliances like phones.

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

[Surt]

How much of that x86 software that simply cannot be ported also can't run on an emulator?

Re:Sparc

[rubycodez]

Oracle/Sun has their own line(s) of x86-64 boxes, which they do own

Re:Sparc

[FrangoAssado]

Even among FOSS software, there's a good chunk that is non-trivial to port to a non-x86 architecture.

Can you give some examples, please? (I'm not trolling, I'm just curious.) I've heard that Debian and recently Ubuntu have ARM ports, but I've never used them. What's missing from these ports that's commonly available in the "normal" x86 distributions?

Re:Sparc

[Sj0]

History shows us that "we can emulate it" is not an acceptable alternative most of the time.

Apple managed to get away with it, but they managed to get away with a lot of dramatic platform shifts because they have dictatorial control over their product. They could switch their entire product line over to ARM tomorrow and apple fans would have no choice but to switch.

X86 and the PC architecture are different than that. They're more democratic, which often means innovation must maintain the status quo or risk losing the base. That's why x86-64 worked so well where Itanium and countless other 64-bit processors (including many with Windows support) failed completely.

Re:Sparc

[afabbro]

Intel is obligated to continue developing Itanium, or HP sues them. Itanium isn't going anywhere, and Oracle is spreading FUD.

I'm highly skeptical of your argument. Are you saying that HP holds an iron-clad contract saying that Intel must develop Itanium for as long as HP wants?

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

[Anonymous Coward]

er... SPARC is dead and going the way of the Itanic. It would be a pleasant surprise if Oracle ( a software company ) was able to pull the SPARC line back from the brink when Sun ( a hardware company ) couldn't figure out how to sell them. There is just too much of a gap to close with the x86 and Power CPUs.

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

[angus77]

Not the most widely used software maybe, but SBCL is taking its time porting to ARM, Clozure CL doesn't have a port I'm aware of, nor does CLISP. The only Common Lisp implemantation I know of that works on ARM is ECL.

Re:Sparc

[gl4ss]

i've seen many sparcs, but itaniums only via ssh.

and current x86's make much more sense. itanium was a flawed research experiment(though, it did live longer than most such..).

Re:Sparc

[dkf]

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?

The ARM does more than x86 per Watt but less per clock. What this means is that which is best depends entirely on what your bottleneck is. If you're cooling-limited (which a lot of installations are, especially when it comes to servers; getting the heat out of the racks and out of the building is the limiting factor) then the ARM looks a lot sweeter because it allows you to pack processors in much more densely. That in turn saves massively.

OTOH, if you're not cooling-limited (and not in a low-power situation like a hand-held device of course) then the x86 makes a lot more sense, as they're fast, pretty cheap and have multiple very well supported toolchains. Those aren't things to be sniffed at.

Re:Sparc

[osu-neko]

Intel is obligated to continue developing Itanium, or HP sues them. Itanium isn't going anywhere, and Oracle is spreading FUD.

I assume you misspoke and meant Intel is obligated to continue producing Itanium (and if so, no doubt the contract specifies a minimum number of units HP has to order each year to uphold their end of the deal, or the agreement is void).

A contractual obligation to continue developing the product would be so monumentally stupid for both parties, neither would waste the time to draft, much less sign, such a deal. If it doesn't specify features or performance requirements to be met by particular dates or the like, it's worthless paper to HP, since Intel could just assign one developer to look at the design for bugfixes and improvements one hour each month and uphold their end. And there's no way in hell Intel would sign one that did contain specifics on future processor features by specified future dates.

Re:Sparc

[SpazmodeusG]

There is an almost trivial migration path that Intel/AMD could take to get rid of those features whilst still retaining a large part of the market. They could produce x86-64 CPUs that boot into 64bit long mode right from the start, scrapping most of the compatibility modes and features (real mode and virtual 8086 mode can go). x86-64 is a really neat clean architecture when taken on its own.

Such CPUs could be badged as "pure 64bit" CPUs. They'd require an 64bit OS and drivers and they wouldn't run older software. That's not such an issue as modern OSes don't exactly run real mode or virtual mode software anyway.

Of course neither AMD or Intel could be bothered doing any of that despite it being a straightforward migration path. The fact is the real estate use of the legacy x68 features are minimal. It doesn't actually hurt to have them around. 386 had 275,000 transistors for all its features, a modern CPU has billions. It's like an bulk freighter with a toy truck in the cargo hold.

Re:Sparc

[dbIII]

On the other hand I have no clue what a "Peterbuilt" is but you can see a Kia in any country. The aim of ARM stuff is cheap and nasty but everywhere.
Also a little nitpick since you are off by about a decade - Intel solved the 4GB problem way back with the Pentium Pro. People think otherwise because Microsoft's low end software couldn't go past 4GB while their high end stuff could on the same hardware. After 1995 the 4GB barrier was a cheap end of town Microsoft problem. Other vendors and linux were compatible with the Pentium Pro even if Vista didn't support chips made after 1995 properly.

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

[Anonymous Coward]

And you can buy 7 of the Intel processor systems for the price of a single Power7 system

bullshit (check ibm.com)

A slight performance advantage for a single generation

bullshit (check spec.org)

and Intel is at least 1 process tech ahead of everyone else including IBM

bullshit (check ark.intel.com, ibm.com)

In 6 months to a year the Intel processor will catch up and then exceed the Power

bullshit (check hotchips.org)

Architecture is irrelevant

bullshit (Intel are now introducing a fucked up FMA 20 years after IBM introduced it (and that 20 is no coincidence))

how much do you want to bet Intel introduce fucked up decimal arithmetic in xeons 15 years from now?

anyway it's good for people like me that there are people like you out there, I guess ;)

Re:Sparc

[jabjoe]

My ARM server is just fine. The debian ARM repositories are massive.

Re:Sparc

[dunkelfalke]

Substitute "Peterbuilt" for "MAN" or "Scania" if you are a fellow European.

Re:Sparc

[juasko]

Apple had the eMate once upon a time :p

Re:Sparc

[bhtooefr]

HP t5325, although it's intended as a thin client.

Genesi Efika MX Open Client. That's intended as a desktop.

(Of course, both of those have badly outdated SoCs.)

Re:Sparc

[bhtooefr]

Citation needed on ARM having an opcode decompresser, with micro-ops and all.

All I'm finding is that it translates Thumb opcodes (which are a subset of ARM, meant to increase code density and, when on a 16-bit data bus, increase performance) to ARM before processing the opcode.

Re:Sparc

[bhtooefr]

And, as of Cortex-A15, ARM is going the same route as that.

The problem with that approach is that it doesn't increase the address space per process, just the address space available to the OS. It's still very useful for many workloads, but there are still workloads that really need the address space to be "real", rather than bankswitched.

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.

Re:Sparc

[TheRaven64]

For a developer, the big thing is valgrind, which is very closely tied to x86 - and quite closely tied to Linux, it only got working FreeBSD and OS X ports in the last year or so. Compilers and runtime environments also need porting. Anything written in [Objective-]C[++] that works on x86 will probably work on ARM. Porting things like Lisp, Java, and .NET implementations is harder, although much easier if they use a common back end like LLVM.

Re:Sparc

[Octorian]

I know we're way too deep in the discussion for anyone to notice, but this brings up an important platform characteristic point that I've mentioned from time to time. Namely, that the whole approach of Wintel involves gross hacks to avoid breaking closed-source software that cannot be patched. Today, the Internet enables patch distribution in a way that mitigates this a little bit, but that's relatively recent in the evolution of these systems.

To compare three major OS platforms, I see it like this:
- Windows: Feel free to lose the source code to your software, we'll bend over backwards to avoid breaking the binary. (though this isn't 100% true anymore, hence the Vista FUD and the need for XP mode in Win7)
- MacOSX: You better not lose the source code to your software, since it will break in the next update if you don't continually maintain it
- Linux: Everything is open-source, so as long as someone cares to use your software, it will get fixed as necessary.

Re:Sparc

[SenseiLeNoir]

Apple switched FROM POWER TO x86, and it had nothing to do with compatibility!

Re:Sparc

[Dog-Cow]

Or substitute "Peterbuilt" for "Peterbilt" if you're talking about trucks.

Re:Sparc

[TheRaven64]

Intel sold their ARM business unit to Marvell. They used to produce ARM-compatible cores (the XScale line), but they no longer do. They're trying to squeeze Atom into that space, and hoping that process technology advances will help close some of the power/performance gap.

Re:Sparc

[JonJ]

Here's another guy thing that sucks. These t-shirts that say: "Lead, follow, or get out of the way". You ever see that? This is more of that stupid Marine Corps bullshit. Obsolete, male impulses from a hundred thousand years ago, "Lead, follow, or get out of the way". You know what I do when I see that shirt; I obstruct. I stand right in the guy's path, force him to walk around me, he gets a little past me, I spin him around kick him in the nuts, rip off his shirt, wipe it on my ass, and shove it down his fucking throat. Hey, listen that's all these marines are looking for; a good time.

People who spout that "Lead follow or get out of the way"-bullshit should get a fucking shot to the head. http://www.youtube.com/watch?v=Mg2OU1zt6jQ&feature=related

Re:Sparc

[TheRaven64]

Oracle has already extended the UltraSPARC Tx roadmap beyond what Sun had announced. SPARC is not dead, Fujitsu is continuing to produce high performance SPARC64 chips (take a look at what Japan's big supercomputers all use) and Oracle is going to keep producing the Tx series. They'd be crazy not to, the Tx sucks for HPC workloads, but it does very a very good job for database workloads. Take a look at what Oracle's using in their showcase fastest database-on-the-planet system: a load of UltraSPARCs.

Re:Sparc

[Coeurderoy]

I'm so disapointed I though it would be something that a dude maned peter has built :-),

Re:Sparc

[camperdave]

screw that, I obstruct

Sadly, what companies do is "Lead, and litter the place with patent minefields so no one else can follow".

Re:Sparc

[drinkypoo]

It's highly HIGHLY unlikely that x86 is going to be usurped by anything any time soon. Part of the reason is, despite apparently every person here's hatred of it, the legacy of x86.

For the vast majority of users you are just wrong. They don't care if their email program changes except that they have to learn the new one. They won't care enough to go find another one. In fact, more and more users never need anything BUT the browser any more, EVER. For these users you are extra-wrong.

Re:Sparc

[drinkypoo]

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.

The other reason, of course, is that they're selling a hojillion of them. If your chosen architecture is the minority it doesn't have access to the same economies of scale.

Let us not forget that using that silly old CISC instruction set also makes code smaller, because of those many opcodes which are only one or two bytes long.

Re:Sparc

[drinkypoo]

Substitute "Peterbuilt" for "MAN" or "Scania" if you are a fellow European.

Uh, no, you mean, "Substitute 'MAN' or 'Scania' for 'Peterbilt' if you are a fellow European". Because the thing which is doing the replacing goes first, and the thing being replaced goes second, and it's not spelled Peterbuilt.

Re:Sparc

[Anonymous Coward]

Substitute "Peterbuilt" for "Peterbilt" because that's the correct spelling of the name ;).

Re:Sparc

[Christian Smith]

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.

While the instructions can be more densely packed in x86 than a typical RISC CPU, x86 often loses out by having more instructions to work round the fact that they have a poor architecture. With only 8 GPR, there is much shuffling of data between registers and memory that RISC CPUs just don't need. Thus, RISC cpus tend not to hit their data cache as hard.

x64 has improved that somewhat, with 16 GPR (the same as ARM).

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.

I think you'll find that, for example, Alpha processors used less die area than their contemporary x86 CPUs. For example, compare the Alpha 21064A with the Pentium, the Alpha has less transistors (1.75M vs 3.1M) and smaller die (186mm^2 vs 294mm^2). That's with the same cache size, and hence roughly the same cache transister count. Which CPU do you think would have been cheaper to make at Pentium volumes?

Same with the original ARM versus earlier x86. ARM was scarily simple (~30,000 transistors?), yet higher IPC than i386.

x86 bang per buck is a volume thing, not architectural.

The difference gets smaller in later generation CPUs, as cache starts to dominate area. Control logic is much less dense than cache, so the extra compatibility transistors of earlier x86 really hurt transistor counts versus contemporary RISC CPUs.

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

Why would ARM need more layers? Adding a 64-bit data/pointer mode would be advantageous, but that wouldn't have nearly the same problems as was encountered with x64, as there would be no fundamental change in the instruction set, just an extension of the register sizes and added instructions to load the extra width data. Other RISC CPUs came through the 64-bit barrier without adding loads of cruft to the architecture. That includes POWER, SPARC, PA-RISC and MIPS.

RISC isn't an implementation thing. It's an instruction set thing. POWER is most definitely RISC.

Re:Sparc

[Yunzil]

Immaterial. The x86 is a lousy architecture and adding onto it hasn't helped any.

Except for letting it become the most successful ISA in history.

I challenge you to show me a single thing Intel can do better now than Inmos could do then.

Dominate the market?

Re:Sparc

[Anonymous Coward]

The x86 and its ancestor the 8008 weren't original at ANY point in their history. The 8008? A binary-compatible clone of the Datapoint 2200. "BCD" opcodes and repeated move? Copied from the Z80's decimal adjust and repeated load. Task state segments and rings? Copied from the VAX's process control block and four execution modes. MMX? Copied from RISC processors' SIMD units. FMA? Copied from the PowerPC. And when they do copy these things, it's either inferior or 10 or more years after the original*. Is there even one innovative thing about the x86? (Pentium floating point and F00F bugs don't count.)

*With a name change or marketing term to make it sound new. I'm surprised they kept "FMA" instead of calling it "HyperMath" or something.

Re:Sparc

[jd]

Depends on how you measure success. Intel has only innovated once - inventing the microprocessor. After that, it has merely borrowed off other people or used price-cutting to kill competitors via marketplace abuse. I don't call that success. I call that failure.

Depends on how you measure market dominance. And, indeed, what market. Intel has a lower marketshare in the HPC market today than Inmos did in 1984, so there exists a market where your statement is incorrect.

Re:Sparc

[jd]

All that the x64 proves is that backwards compatibility is a good thing. If you developed a wholly new architecture and allowed it to run x64 code at x64 speeds as an uploadable microcode extension, it would do just as well as any "native" x64 processor.

Alternately, if you had a wholly new architecture and wrote a binary-to-binary cross-assembler which appeared to "install" x64 code on the box but actually installed code rewritten for the new processor, it would also likely sell just as well as any "native" x64 processor.

Nobody WANTS an ix86 or x64, and only geeks even know what these even mean. What people want is their software to work and work well. They don't give a shit how.

And that is the part you are utterly ignoring. You are mixing up the desired end result with one and only one (inferior) method of achieving that result. There are no practical reasons for the x86's survival, there are only practical reasons for machines that can run x86 code, which is a very different thing altogether.

Re:Sparc

[jd]

Let me put it to you simply. In order for Intel today to beat Inmos back then, a single core from a single Intel CPU would have to have greater horsepower than a Cray X-MP. That is the figure you'd have to beat in order for the largest possible tightly-coupled SMP box of modern Intel processors to be - in any sense - better than the largest-possible tightly-coupled SMP box of Transputers. Are you willing to make that claim?

Re:Sparc

[dunkelfalke]

Thanks for the correction.

Re:Sparc

[Anonymous Coward]

Except that this best stuff came from AMD. Intel said 64-bit was not in their interest on the desktop.
AMD64 is the reason x86 is winning. Intel had to do a massive u-turn.

Re:Sparc

[blair1q]

On the low-power mobile and embedded side x86 is out.

You're making the implicit assumption that this is because it's x86.

It's not.

It's because Intel has decided (because you know they studied it financially from every angle before deciding) that the market isn't profitable enough. Yeah, there's a zillion units being sold and $billions being made, but if it's below Intel's %ROI cutoff line, it's cut off from money, manpower, and technological redevelopment mindspace.

The result of their refusal to dominate the segment is that there are a slew of competitors each taking little pieces of it. And now that handsets are commonplace, the low-hanging fruit are gone and it's not going to get profitable enough ever again for Intel to wade in. Not unless someone there just happens to have a random breakthrough that gives them a big--not small--edge for no effort invested.

Frankly, I bet there's half a dozen people posting here who could start companies to design chips to compete with ARM et al. The low-power side of the industry has always been easier to design and less profitable (which, circularly, is why Intel never made it a bigger deal, since they make a lot more money pushing heavy-duty mainstream low-barrier-to-entry computing).

Re:Sparc

[bored]

OpenRd, loose definition of desktop, but you can plug in a monitor/keyboard, and if you need more than the built in flash, it has a esata port. I run my NAS on one, but its more targeted towards desktop type behaviors.

Google it.

Re:Sparc

[bored]

RISC isn't an implementation thing. It's an instruction set thing. POWER is most definitely RISC.

Giggle, have you ever done any assembly on PPC/POWER? Its got a lot of really nasty asymmetric areas. POWER may be RISC by dogma, but it sure isn't RISC by MIPS/ARM standards. It is absolutely a LOAD/STORE arch, but a very serious argument could be made that its not RISC. I think this is generally accepted in most circles to be true.

BTW: Since POWER4 it has an instruction decoder that decodes to microops (or whatever you want to call them), just like x86 has since the PPRO/K6. These are then bundled and scheduled. Makes sense when you consider things like rlwimi/loadall.

Re:Sparc

[Surt]

I honestly think today is a pretty different day in computing history. Today, about 3/4 of the applications I care about are browser based, and run on any hardware platform. By next year, 90%. At that point, I could probably switch off x86 without caring. Ten years ago, only about 2% of what I cared about was browser based.

Within 5 years, I doubt if more than 1% of what I care about will require a fast x86. 99% will require fast javascript/flash/html5 execution.

Re:Sparc

[Anonymous Coward]

fucktard, I write software for a living. Compiling the same system with the highest optimization available on a p7 system with IBM compilers vs using gcc on for Nehalem gets a system that runs nearly twice as fast on x86. Blow it out your ass with the spec. I assume you actually built software you wrote on both systems and formed an educated opinion? Not likely, asshole.

Re:Sparc

[WorBlux]

It's highly HIGHLY unlikely that x86 is going to be usurped by anything any time soon. Part of the reason is, despite apparently every person here's hatred of it, the legacy of x86.

Like the 5 trillion dollars worth of COBOL code that will only run on Intel Mainframes?

Re:Sparc

[juasko]

Sigh, todays cpu's does not only use 128bit internally but 256 bit processing. Heck a PPC G4 had vector processing at up to 256 bit.

So your non usefulness of 128bit is plane nonsense. Then if 128bit memory addressing is needed is a totally different topic. But in this context the 128 bit does not refer to memory addressing. But to (cant get the english word) "computable precision"?.
Ever consider problematics within 3D programming and rendering? 256 bit is sometimes even way to low to allow needed precision. Instead you hack your way to allow computation to happen with smaller precision.

Also just take the G4 as an other example, it's still probably the best cpu and chipset to handle Firewire. Some studios did not go to the G5 cause the G4 performed better when it came to signal handling.

I wonder where the Intel cpu today stands no clue, not been following. But the Intel architecture is rubbish compared with what is out there. Yes it's the most successful architecture, but just as windows and dos back in the day was plain rubbish compared with any other system out there, they where the most successful. But ranging from SGI trough Amiga to Mac systems it was plain rubbish.

Just look at the memory handling differences between 32bit and 64bit windows. 64bit windows is way faster, why?, it should be slower.
But it's all due to the old crappy intel architecture.

But when that said, Intel is pretty much the only alternative out there for todays desktops. I'm sadned that IBM didn't push the PPC architecture more. Just as I'm sad Alpha got in wrong hands. The only good thing with todays situation is that almost everything is intel compatible. And it has it's own pros. But todays computers would probably been quite different if the world hadn't chosen intel and ms.

Re:Sparc

[bhtooefr]

Ah.

From the Cortex-A8 reference manual:

Instruction-specific scheduling information

This includes the number of micro-operations for each main instruction and the source and destination requirements for each micro-operation. The processor can issue a series of micro-operations to the execution pipeline for each ARM instruction executed. Most ARM instructions execute only one micro-operation. More complex ARM instructions such as load multiples can consist of several micro-operations.

Re:Sparc

[quantum bit]

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

Customers aren't stupid. It's blatantly obvious what Oracle's motivation is, and everyone I've talked to in the industry knows it. It's a direct shot at HP, aimed at sinking HP-UX. HP-UX + Oracle on Itanium is a very popular platform in the high-end monolithic database market, and Oracle is salivating at the idea if trying to convert some of that to Solaris + Oracle on SPARC.

If Itanium is dying it's only because Oracle just killed it. They're hurting HP and pissing off their own customers by cutting off development for a platform that many companies invested in, not just in the past, but new generations of servers being developed and solid right now.

Well screw them. We'll just go with x86-64. They can't kill that platform without committing corporate suicide. Now if you'll excuse me I need to go order a Dell server and try to suppress the vomiting.

Marketing Coup

[Anonymous Coward]

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.

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

that's still around?

[Ultra64]

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

Re:that's still around?

[blair1q]

It's still being used in certain proprietary big-iron systems. And it still kicks some ass. But it won't supplant the genetic ingrainment of x86. Which itself is hardly x86 any more. Intel is still selling it, but only the foolish are buying it to use in new designs.

Re:that's still around?

[the linux geek]

It's still around and a valuable tool in the toolbox. The next-gen one (Poulson) should be the fastest processor in the world at release, assuming Intel manages to get it out on time.

Re:that's still around?

[Anonymous Coward]

should be the fastest processor in the world at release, assuming Intel manages to get it out on time.

That pretty much sums up Itanium.

Re:that's still around?

[dreamt]

Well, believe it or not, its also still being used for new VMS servers (yes, another technology that is still alive and kicking).

that's okay

[Anonymous Coward]

Kate Winslet will get fucked first.

Can't blame them

[atari2600a]

It was botched from the start w/ no x86-32 backwards compatibility, & to make matters worse this weird AMD company takes the existing X86-32 architecture & just extends the buses & registers 2x creating a more successful architecture. On top of that Intel only sold Itaniums to enterprise, screeching compiler development for it to a hault.

Re:Can't blame them

[mbkennel]

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

except for maybe Intel's compilers?

Intel's compilers are very very good. Intel inherited the old DEC compiler group (which was very skilled) after some woeful time at Compaq.

Re:Can't blame them

[atari2600a]

Yeah but think about it, most enterprise users will likely be using FOSS or some variant, & try getting Gentoo installed without GCC :P

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:Can't blame them

[the linux geek]

No they won't. They'll be using HP's compilers.

You think Linux is the platform of choice for high-end RISC servers? Seriously?

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.

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:Can't blame them

[ppanon]

If you were looking at Intel roadmaps in the late 90's you would have seen that Intel wanted Itanium to not be just a niche high-end processor but to eventually take over the high-end commodity market by keeping x86 32-bit and having increasing memory requirements beyond a 32-bit address space gradually force people to shift to Itanium.Two things stopped that from happening, a) bad performance of interpreted legacy x86 code on Itanium, and b) AMD coming up with 64-bit extensions to the x86 instruction set.

Re:Can't blame them

[rubycodez]

Not true, welcome to the 21st century.

You can get x86 processor modules for the Unisys Dorado that run Window, Linux and x86 Java VM. And the midrange Dorado 4000 and Libre 4000 actually USE intel xenon. http://www.unisys.com/about__unisys/news_a_events/05158777.htm
,
You can get x86 processor modules for the IBM Z series, same deal, run Windows and Linux and x86 Java VM.
The IBM PowerVM Lx86 emulator lets one run x86 linux applicatoin on PowerPC

Re:Can't blame them

[rubycodez]

should have mentioned, in a Solaris / Sparc shop, if there is need to run on x86, then of course slap x86 Solaris onto a supported x86 box

Re:Can't blame them

[the linux geek]

You can't get x86 modules for z. I know. I run one.

Lx86 lets you run x86 linux applications... just like IA32 EL on IA64. Emulators aren't interesting.

Re:Can't blame them

[rubycodez]

I was referring to the zEnterprise BladeCenter Extension, which IBM is boasting can have x86 blades. Not all Z series models can integrate with the zEBCE

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

[the linux geek]

HP claims to have a 10-year roadmap. I suspect there's a contractual clause that says if Intel kills IA64 development, the IP and some amount of money gets transferred to HP.

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

[Anonymous Coward]

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.

I believe it was HP that decided that designing (and production, this was the days of "Real men own fabs") the next gen was just too expensive to continue for a low volume chip like PA-RISC. Intel made them an offer they could not refuse (taking on the HP chip designers, and modifying the architecture to HP's liking, and committing to production). I believe that if AMD had not kicked Intel's butt with the Opteron (and its 64-bit extensions) Itanium would be a likely leader today (as Intel would have dead-ended the x86).

Re:The processor that sunk HP's UNIX line

[Anonymous Coward]

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.

So you're saying that HPUX would be popular otherwise?

They were already well on the way to irrelevancy.

Re:The processor that sunk HP's UNIX line

[Darinbob]

Kind of sad. PA-RISC was a nice design and very fast. The problems are more business oriented. Developing your own chip is expensive, so companies either want to be chip makers, or computer builders, but not both. Second the high end market made a leap from being unix oriented servers to Windows based servers. So customers don't like oddball chips that their software suppliers don't support. And in this context, "oddball" means anything that isn't x86. It's is also convenient from a business perspective if your desktop IT staff can be interchangeable with the server IT staff; then you can dump the unix guys with their funny beards and and the big-blue guys with their starched shirts and replace them cheaper cogs.

Re:The processor that sunk HP's UNIX line

[davidgay]

You may have long argued that, but if you actually looked at its history (how the architecture was defined, etc), you would actually understand that Itanium(ic) is a not-very-successful(*) joint HP-Intel project.

David Gay
*: For ambitious definitions of success.

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:The processor that sunk HP's UNIX line

[Anonymous Coward]

x86 is also copyrighted. Regardless of how wonderful PA-RISC may have been, HP had no choice than to find a 3rd party to source processors since they could not afford to develop in-house CPUs any longer.

I don't think most people in this thread understand the economics involved in getting a high end CPU out of the door, given the relatively small market for PA-RISC systems that architecture had simply priced itself out of the market. Period.

By the mid 90s, HP had already sold most all of their fabs. And all of the PA-RISC 2.0 parts had been fabbed elsewhere (IBM mostly). So HP could continue paying IBM which was a direct competitor in their most lucrative markets, or go with Intel which was already providing them the CPUs for their PCs. What choice would you have made?

Re:The processor that sunk HP's UNIX line

[Sj0]

Seems unlikely to me. Intel would have moved away from x86 if it could. Thinking about it, the whole architecture is something they don't have very tight control over, as the very existence of AMD and other competitiors show. If Intel had been able to lock the world into something like the i960, I'm sure they'd be happier than a pig in shit.

Intel may have tried to push Itanium, but it wouldn't have worked. They were hardly able to push it as a server solution.

Re:The processor that sunk HP's UNIX line

[dhavleak]

Can you share some information about the nature of this meeting, and what kind of contract your team was evaluating? (especially considering this should have been at least 8 to 10 years ago)..

Itanium, from an engineering standpoint was a perfectly good architecture -- there are several scenarios in which VLIW architectures can attain truly astounding IPCs. It's weaknesses were essentially software support, power/heat, and price -- which is a vicious cycle of problems -- without software support, you don't get customers, without customers you don't get the volume to keep prices down, and you can't invest in advancing the architecture. If that wasn't enough, AMD's announcement of 64-bit extensions to x86 was pretty much the nail in the coffin for Itanium. I'd argue that Itanium's failings were essentially business related -- the chip itself was pretty cool.

Re:The processor that sunk HP's UNIX line

[Anonymous Coward]

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

I think this chart says it all. Really funny!

http://news.cnet.com/2300-1006-5873647.html

Re:The processor that sunk HP's UNIX line

[MemoryDragon]

Actually it was worse, back then PA-RISC died, Mips on the server also died and Sparc Alpha also was cancelled, because everyone was so afraid of the Itanic.
This paid off Intel big time, because they suddenly got a stronghold into the Unix server market, a high price segment where they were ignored before.
I guess the entire Itanium development has paid off for Intel 10 times already.

Re:The processor that sunk HP's UNIX line

[MemoryDragon]

Actually you got intels plan right, it was less about bringing out another processor line and more along the lines of trying to kill off the entire clone market by trying a full 180 degrees. Wellt he result is it killed superior risc chips and intel never wanted to get x86 towards 64 bit so AMD did it with a sane solution and intel had to follow.

Re:The processor that sunk HP's UNIX line

[dreamt]

Its not even just new HPUX systems. Its also new VMS servers (also from HP).

Re:The processor that sunk HP's UNIX line

[Locutus]

if HP still has their design teams around then one possibility might be to look at going to ARM. There's been lots of talk about using ARM in server class systems and it wouldn't be looked at like a completely new architecture. If any team could make a go of using ARM designs in server class devices successfully, the PA-RISC / Itanic teams could. IMO

And that would allow both HPUX and GNU/Linux into their customers data centers with mostly just HPUX rework.

LoB

Re:The processor that sunk HP's UNIX line

[John Bayko]

Itanium was basically a DSP, making it fast. But DSPs are terrible for anything with branches, interrupts, traps, etc., so almost every interesting feature added to Itanium exists to compensate for the inherent weakness of a DSP design for non-DSP tasks. It worked out in the sense that it was still fast at DSP tasks while not being slower than regular CPUs at regular tasks, but the DSP style workload turned out to be not significant enough to justify that complexity. And recently GPUs or other hardware (PowerPC Cell extension, coprocessors, multi-core) are being used for that instead.

Re:The processor that sunk HP's UNIX line

[dhavleak]

If that were true, the Itanium would have A2D and D2A convertors on it, a very minimal integer unit and multiple hardcore floating point units on it. DSPs certainly are terrible for branches / interrupts / etc -- but that wasn't the Itanium's problem. Specifically, speed (as a CPU), was not the Itanium's problem -- it was (is?) a perfectly viable CPU architecture, with some crazy compiler control of branch-prediction and speculation, and moreover was a very clean implementation free from legacy cruft (ala x86/amd64).

None of this is surprising information -- this is not the first or last time that a good CPU architecture (or any good piece of engineering) will have fallen by the wayside due to market forces. It's probably even preferable this way -- AFAIK Intel/AMD/Via's cross-licensing agreements only extend as far as x86 and extensions thereof (amd64/em64t/sse/sse2/etc.) are concerned. Intel would have been under zero obligation to license the Itanium ISA to anyone else to come up with competing (compatible) designs. If Itanium had succeeded, Intel would surely have made low power variants that were suited to desktops / laptops / ultraportables, and ultimately gotten rid of the x86 legacy/burden, and also gotten rid of the competition in the process. I'll take a brain-damaged architecture over that set of events. But ia64 itself was pretty darn awesome.

Re:The processor that sunk HP's UNIX line

[John Bayko]

I didn't mean literally a DSP like you'd find in a CD player, Itanium was always intended to be a server chip. But features like no integer register multiply, in order to keep all integer instructions to a single cycle - integer values have to be moved to floating point registers for multiplication, then back.

I like a lot of the quirky features, especially the extensive use of flags to defer exceptions (like a missed load) allowing speculative operations to work safely before the condition is known. But it was all designed for "avoid unpredictability at all costs" like a DSP, rather than other CPUs designed to manage unpredictability using caches, buffers, multithreading, and so on. And as I said it was successful, but the strengths weren't as useful in the real world as I guess they expected, since the costs of things like memory access and interrupts just keeps rising, and since they can never be eliminated completely, at some point it needs to manage it anyway (remember the i860 had exactly the same problem). And now special hardware like GPUs are being applied to the problems now instead, so the advantage it does have is smaller.

Re:The processor that sunk HP's UNIX line

[Anonymous Coward]

Makes sense..

Is Larry's foot sore yet?

[linatux]

Itanic now only used for HP/UX. Those big customers are forced to move to a different platform. Why would they continue to choose Oracle - the company that forced them to move?

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.

Re:Is Larry's foot sore yet?

[cblguy2]

Yup. We purchased a number of VMS boxen within the last year. The Itaniums run solid with VMS, albeit HP stuck enough fans in there to make the box uncomfortably loud (data center only, nobody wants one of these things anywhere near their office, even as a test platform).

Re:Is Larry's foot sore yet?

[Eunuchswear]

Of course non-stop has already changed instruction set three times, so it might not be too hard to move it to something else.

Re:Sink the itanic?

[linux_geek_germany]

What's up with this goatse bullshit????? Nobody cares viewing it the umpteenth time, nobody at /. will be upset by it and you just fucking waste our valuable time... YSSCGKY!!

Ask Intel about Itanium Compilers

[Anonymous Coward]

Ask Intel how committed they are to Itanium since they just dropped support from their compilers.
They're probably just running out the hardware development pipeline.

Make now mistake about it, Oracle is a vicious competitor but this time they might have just made the correct technical decision.

Re:Ask Intel about Itanium Compilers

[stevel]

Ask Intel how committed they are to Itanium since they just dropped support from their compilers.

Not true.

Re:Ask Intel about Itanium Compilers

[rubycodez]

put down the crack pipe, in January Intel came out with C++ version 11.1 update 8 for Linux and Windows on Itanium

Re:Ask Intel about Itanium Compilers

[Anonymous Coward]

Check the C/C++/FORTRAN 12.0 release notes.

Re:Sink the itanic?

[pookemon]

(a) Don't feed the trolls (b) It's /.'s lacking security and poster verification that allows crap like that to be posted over and over again.

No worries.

[Anonymous Coward]

Whatever happens, its heart will go on.

Titanic

[Anonymous Coward]

Hard to sink a ship thats already resting on the bottom.

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:Ah well

[Saint Stephen]

Excellent post!

Well...

[jakartus]

It seems the elephant in the room just farted.

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

[rubycodez]

IBM stopped DB2 support for Linux on Itanium with version 9, 9.5 doesn't support it....guess that leaves Websphere for HP/UX, that bloated piece of shit that is excuse for IBM to suck a client dry with consultants to attempt to make it useful

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

Re:Oracle Had a Lot of Itanium Software

[metamatic]

IBM stopped DB2 support for Linux on Itanium with version 9, 9.5 doesn't support it....guess that leaves Websphere for HP/UX, that bloated piece of shit that is excuse for IBM to suck a client dry with consultants to attempt to make it useful

Not true, you can download DB2 Data Server 9.7 for Itanium from IBM's web site. [Opinions mine, not IBM's.]

Re:Oracle Had a Lot of Itanium Software

[rubycodez]

That includes HP/UX on Itanium, but if you look after version 9.0 they throw Linux Itanium customers under the bus

NEC's ACOS

[BBCWatcher]

I think NEC has already started to transition ACOS to X86. (Itanium doesn't offer any value-add to ACOS except perhaps avoidance of endian emulation.) But who cares? ACOS is exclusively supported in Japan, is in maintenance mode only (like Hitachi's VOS3 and Fujitsu's MSP and XSP), and has even less marketshare than those Japanese competitors. If you collected all the Itanium chips NEC sold in a year to run ACOS they'd easily fit in a shoebox.

Re:NEC's ACOS

[the linux geek]

ACOS-2 is going to x86, but ACOS-4 is, at least currently, still on IA64.

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.

Re:Ya HP is calling bullshit too

[afabbro]

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.

The only people running "massive DB servers" on Itanium are people who had HP-UX shops before PA-RISC went away and migrated to Itanium. I don't think I've ever met anyone who went out and bought HP-UX + Itanium and introduced it into their shop.

Itanium is a fine processor - but it solves all the wrong problems. It's fantastic for scientific compute apps - 64 64-bit registers, woo-hoo! - but it's not really a competitive solution for mainstream business use.

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.

I don't think anyone has made better moves over the years that Oracle, in terms of understanding where the market is going and snapping up or eliminating competitors. They're brutal competitors and are not stupid.

Re:Ya HP is calling bullshit too

[TheRaven64]

Itanium is a fine processor - but it solves all the wrong problems. It's fantastic for scientific compute apps - 64 64-bit registers, woo-hoo! - but it's not really a competitive solution for mainstream business use.

It's fantastic for scientific compute apps if you have a team of people capable of writing Itanium assembly. If you're relying on what the compiler spits out, then you may as well go with a cheap x86 chip - the theoretical throughput will be a lot lower, but you'll stand a much better chance of getting close to it.

Re:Ya HP is calling bullshit too

[afidel]

HP wins plenty of new clients with both HPUX and NonStop. This is all about Oracle trying to weaken HP which they have a hardon for ever since HP ousted Larry's buddy Hurd. Now, if I was an Oracle and HP customer I would probably be talking to my lawyers as Oracle dropping support for a competitors fully supported hardware and OS platform while customers have active maintenance agreements sounds like breach of contract to me. Luckily my needs are much more modest and so I just run Oracle on Windows on x64 hardware.

Commercial software for Itanium?

[damn_registrars]

I didn't know there was any. Oddly enough the Itanium has a pretty active Linux community - check out gelato.org. Frankly it has been such a niche market anyways that I didn't think anyone still bothered releasing any new software for it other than dedicated open source guys who were recompiling everything they could get source code for (since that is what you use 90% of your actual time for on an Itanium anyways - compiling software).

Quite simply, I'd be surprised if anyone who used Oracle on an Itanium actually cared about new releases.

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.

Re:Commercial software for Itanium?

[Anonymous Coward]

I'm willing to bet my left nut that 99.9 % of the Itanium "open source community" was working on Itanium Linux because that was their job. Itanium is not and has never been a hobbyist platform - the only traction it ever got was in high-end servers, and specifically high-end HP servers.

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:Why not post intel's response?

[Anonymous Coward]

Did you notice that the word "strategic" is missing from Intel's announcement?

Re:Why not post intel's response?

[Anonymous Coward]

FUD like this coming from a name as large as Oracle may actually create a self-fulfilling prophecy. (Hint: Intel may have no choice but to cancel the Itanium if they can't sell it to anybody.)

Re:Why not post intel's response?

[Macka]

The reason may have an element of FUD to it, but the consequences aren't. People don't buy computers to just sit there running an O/S, and the majority of HP-UX Itanium builds I used to be involved with were commissioned to run Oracle. So this is going to hit HP Itanium sales hard and HP Itanium customers even harder.

Oracle seem to be getting more ruthless in recent times. They aren't playing very nice with Red Hat either as they've killed off support for ASMLib and OCFS2 on RHEL 6. Clearly an attempt to force customers wanting Oracle RAC clusters on Linux off RHEL onto Oracle's own Red Hat clone. Small wonder that Red Hat have reciprocated by making it harder for Oracle to get a free ride on the work Red Hat put into the kernel.

Re:Why not post intel's response?

[Kuad]

Ah, but the rumour is that Poulson is *IT* for Itanium. There will be process shrinks with more cache and perhaps the odd feature bolted onto it, but the word on the street is that this is the last microarchitecture for the Itanium line. That will last Intel out through any existing government contracts and whatever agreement they have with HP. It will probably allow HP to get to the end of all their VMS contracts, too. (Pity, because porting VMS from Alpha to IA64 was a bitch, but they *had* to do it)

It's already sunk

[Anonymous Coward]

It's surprising how few noticed Intel dropping support for Itanium in their compilers a few months ago.

Itanium is, for better or worse, dead. (Having said that, I'd take an Itanium box over a SPARC one any day of the week.)

Re:It's already sunk

[rubycodez]

I prefer them with a bit of soft silky hair myself, east asian chicks for the win!

Dang Windows

[Billly Gates]

You know smartphones and servers do not have the same issues of a one 1978 era set of instructions compiled executables that have to run only under one platform.

I know Windows NT was first designed on a Mips but that did not help. Maybe byte code interpreters like those on Android will save this. It is a tragedy.

But, in fairness Itanium did suck quite hard compared to Alphas. They overclocked them and crippled the alpha and tried to make their FPUs increadible powerful to do some nice benchmarks. Even with Alpha dead the chips could not do hardware supported threading like Sun's Sparcs nor could it have the performance of a fast AMD Opteron. Intel just had no choice but to make the Core2Duo and i5s and i7s that killed it. ... come to think of it Oracle now has sparc processors. I sense to support Itanium would be a conflict of interest at this point.

Itanium?

[dicobalt]

What the heck is an Itanium?

Re:Itanium?

[Eunuchswear]

It's the manufacturers name for what everyone else calls the itanic.

who cares

[Anonymous Coward]

all 2 customers impacted are disappointed

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.

Hmm...

[Anonymous Coward]

At first I was wondering why Intel would want to sink the Titanic...

Yay?

[parlancex]

I don't understand why this is tagged 'yay'. What this means is that the world's largest chip maker with partnership from the world's largest software company couldn't get a competing architecture off the ground in any meaningful way. That's not yay, that to me is just a little sad. Sure we have great designs beneath the all the baked-into-silicon legacy x86 translation, but as developers (especially the developers of compilers) we'll never get to see any of it, and we'll never get to reclaim any of that silicon for something more useful either.

Re:Yay?

[Sj0]

Lamenting silicon use is a little silly, from where I'm standing.

If you look at a modern processor, the entire decision-making part of a chip is absolutely miniscule. The biggest hog of silicon is cache.

x86 and the PC standard is a boon to everyone. If you want to see what computers would look like without the benefit of the open architecture, look at smart phones -- even Android, fully open source, has people begging for updates to their phones OS because everything is too locked down and proprietary (and non-standard) to let things like linux thrive.

Re:Yay?

[gl4ss]

it's a yay, the plat sucked. they can use the engineers for something else now. it competed for a LONG TIME - and did not do well.

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

[Anonymous Coward]

"So much money was poured into x86 you just got more for your money with x86"

That doesn't make as much sense as you think it does.

Re:It's just ARM heads

[Anonymous Coward]

POWER5 is nearly 7 years old. If you want a better comparison to Intel's latest offering, both in terms of performance and energy efficiency, check out POWER7: http://en.wikipedia.org/wiki/POWER7

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.

Re:It's just ARM heads

[Anonymous Coward]

While I understand your wanting backwards compatibility do you really achieve that much with games? Try playing an original Master of Orion II on windows vista or higher. I agree that it would be nice but I think what we really need is to move to more virtual machines. Whether that is JVM or some new LLVM-style bytecode. As another aside given all of the hardware dongles and activation server crud we are dealing with I wonder for how much longer actual backwards compatibility will matter since the protection schemes make it obsolete.

Re:It's just ARM heads

[John Bayko]

You're forgetting that Windows wasn't unique, it had competitors: OS/2, GEM, GEOS were the main ones. That was the competition, not Unix. Unix vendors made token efforts to support a GUI, but their efforts like Motif and CDE were a lot like lipstick on a pig.

Microsoft had a few strategies it used. Some could have been done by competitors, such as the major emphasis on developers with VisualStudio, VisualBasic, frameworks like OLE, and so on (there was no good equivalent for the others). Some essentially expanded Window's scope by supplying its own software with Word, Excel, etc. which were integrated into Office. Some involved less honest things, like hidden OS features for MS applications, or actively sabotaging competitors with OS releases (DR-DOS, for example). And a big part was back room deals, leveraging decision makers with money, promises, and threats, like the "per-CPU licensing" which charged a Windows license for every computer shipped, even if it had no Microsoft software on it, making it more expensive to include competing software (like OS/2) because they would have to pay twice. Also the intense fight to kill Apple's QuickTime codec, and the sales force targeting technology ignorant management of companies, taking technology decisions out of the hands of technology specialists.

The final strategy was more of an accidental one: Windows and other software was just so badly designed that it couldn't run on other CPUs. In fact, often it couldn't be made to run using the same CPU on better hardware. Do you remember the "640K limit"? Hardware that got rid of that limit was also incompatible with a lot of MS-DOS and Windows software and drivers - badness was actually required for Windows. With a situation like that, every application that was made Windows compatible became stuck, depending on it. Trying to make software portable was almost as bad as writing two completely different versions, so the first version was always for the bigger market. The race for new versions meant there was always a new version needed, so often no time to work on any other versions, so anything non-Windows just wasn't as good, or just didn't exist.

Hence the "Windows ecosystem" accumulated marketwise, while a very clever CEO leveraged every strategy businesswise, and drove out all competitors - while at the same time requiring Intel x86 compatibility, purely as a side effect.

Re:It's just ARM heads

[TheRealGrogan]

No, "dumbing down" doesn't just mean making it easier for users, it means changing things to make it easier for users, according to what the developer thinks a user should be, at the expense of making it more difficult for more advanced users, or impossible for them to carry on in the manner they are accustomed to. Taking away their choices.

Windows Vista/7 are like that in their user interface. Gnome is like that. KDE 4 is like that (though in their case, I think it's a matter of adding options later as it's improving in configurability with every release). New versions of Microsoft's programs are often like that (I despise what's become of Microsoft Office for that). Most new PC game titles are like that. (dumbed down like the consoles)

Linux/ARM/Whatever aren't necessarily failing... these technologies aren't trying to dominate the desktop computing scene. It's getting quite tiring to see this time and time again.

If you think Windows is smart for maintaining all that backwards compatibility cruft, think again. Have you ever poked your head into the WinSxS directory? Check all the different versions of runtime libraries stored there, that get called when you run older applications. The size of that directory increases to mammoth proportions as the Windows installation ages, too, as more things get installed and upgraded. Irresponsible gyrations... fuck I hate that crap.

Linux doesn't break old binaries either if they can help it. There are still backwards compatible kernel options that will take you back to libc5, aout binaries. I don't run anything that old, but I've still got stuff from many years ago that still can be made to run, by (at worst) dropping older versions of a few libraries into the program directory and setting LD_LIBRARY_PATH

Re:It's just ARM heads

[boxwood]

funny you mention Master of Orion II: it works flawlessly on Ubuntu. Just double-click on Orion95.exe and "it just works".

Because of all the great work done on wine, it getting so that Linux is more backwards compatible with old Windows programs than Windows itself is.

The OP probably tried Linux 10 years ago, had a bad experience, and just assumes that nothing has changed since he last used it. Nowadays I think I have more technical issues with windows that require me to go into the CLI or registry editor than I do on Linux. And when I do have a problem a quick google search almost always yields the answer within a couple of minutes, while a Windows problem I have to go through several pages of google results, wade through page after page of badly formatted forums full of those annoying ads that cover everything until I click the close button, and still only get half an answer and have to figure out the rest through trial and error. And if I can't find an answer on a linux problem I can go over to ubuntu forums and get a helpful and friendly answer from a fellow linux user within a few hours. Many windows issues I have I end up just having to ignore because a fix just can't be found.

We're now in a bizzaro world where linux is more user friendly than windows, has less need for a CLI than windows, linux users are more friendly than windows users when asking for help (and are still better informed).

Most older apps can be easily run via wine. For the few that can't, I find it nice to keep a windows install in a virtualbox and use that for those odd little apps (there are very few now).

Linux works great for the casual computer user. They can browse the Internet, listen to music (and keep their collection organised), watch movies, etc. There is no need for virus updates, or spyware scans. You plug in a USB device, you don't have to find the disk to install the driver for it, it just works. I had a dual boot setup on my mother's system because I don't like forcing people to use Linux, I just like giving them the option. I tried to boot to windowson her system to update things, and nothing was working. I asked her about it, she just shrugged and said "I don't know, I don't use that anymore".

I've said time and again the only group of people that hate Linux is the so-called Windows "Power User" type. An advanced user likes the stability and openness of Linux. We can go in and tinker with ever aspect of the OS if we so choose. A beginner likes Linux because there's a lot less work in maintaining the system (no virus scanner updates, spyware scans, and god forbid your windows gets infected with something... better call a tech). But the "Power Users"... they have a lot of time invested in learning all the registry tricks, knowing the best virus scannign software (what is it now? MS security essentials or something like that?) which software to use to scan for malware (is it still spyware S&D?). They've spent all this time to get all this OS specific knowledge they don't want to start on a new OS and have to learn things like a beginner user. And these are the people who are managing the IT departments. These are the people that the home user goes to when they have a problem with their PC. It doesn't matter that Linux has solved all the problems the OP mentioned. It doesn't matter how many problems Windows has. The Power User actually likes the problem that Windows has because they know how to fix them, and when they fix those problems for their friends their friends oooh and ahhh over how smart they are.

Oh well, at least my computer works the way it should.

Re:It's just ARM heads

[hairyfeet]

Ubuntu 10 new enough for you? I'm so sick of this "He tried Linux 10 years ago" bullshit where you FOSSies stick your damned head in the sand and pretend your asses don't stink. You want to know why Linux suck massive amounts of ass, do you? I'll be happy to tell you it is because Linus is a massive douche who won't allow you to have what everyone else from Windows, BSD, hell even OS/2 has had for a fricking decade, and that is a stable driver abi.

Want to know what happens when you upgrade (which you fucking have to do thanks to the 6 month death march)your lovely Linux? Oh look half my damned drivers don't work now and the ONLY way to fix it is 5 hours in the God Damned CLI which frankly needs to DIAF. Don't even compare yourselves to Windows and Apple because between Win 7 and OSX SL you guys are MAYBE at Win95 levels. And Wine? Yeah because the average user knows how to spend 4 hours fucking with funky CLI to get their apps to work, only to have it shit itself and die when the death march breaks everything again.

Linux is a great SERVER OS but as a desktop it is ass, and it is ass because the head of the thing is an asshole. Don't believe me, take it from the mouth of the man himself who says "Linux isn't designed, it grows like a virus " LOL, you have the fricking main developer who admits there is NO plan and shit just grows like a fungus, and you wonder why drivers don't work? Well fricking duh!. Link is here read it yourself. His excuse, which is just like an asshole in that it stinks, is that it would lock down the kernel, aka he wouldn't be able to break shit anytime he had an itch. Well fuck you Linus, you are holding the world back and need a good firing. The reason why sites like this exist is because all the excuses fanbois have to come up with to cover douchebags like Linus keeping Linux down.

So do us all a favor and don't bring up your hobbyist crapfest when we grownups are talking Windows or OSX, okay? Your shitty backwards ass design makes it a perfect example of developer hostility, with ZERO backwards compatibility, even for the fucking drivers, and CLI is a damned God to you people. It is the most backwards ass fucked up POS I've ever had the displeasure of touching, and it is about as ready for the public as dropping them all in Plan 9 and expecting them to do everything with a 70s era term (You can stick your CLI BTW, as the public has already said in 50 foot letters DO NOT WANT).

And I got news for you sparky, the ONLY reason why Linux has a hold in servers is the fact that Windows CALs are a damned mess. If MSFT was to drop them to a simple $1 a slot Linux would dry up and blow away like a fart in the breeze. Even my old CLI head admins admit that the new WinServer is a fucking cakewalk to manage and the crazy price of CALs keeps them away. So any market you have there is just a gift from the MSFT middle management, sorry. Embedded you kick MSFT's ass, as they don't do tiny anything.

But until you fire that douche Torvalds and get a real designer in there and make it so I NEVER have to deal with CLI and NEVER will my customers have to deal with same? It is a giant DO NOT WANT. Frankly there is a good reason why even with a price of nothing it has gone nowhere, and that is because free shit is still shit.

Re:It's just ARM heads

[WorBlux]

I like to Run MOO and MOO2 as well as other win95 era games in DosBox (which last I heard was being ported to the ARM architecture) simply because there are fewer side effects than installing into the wine prefix. I can emulate the fastest Pentium system with a vga and sound card, so performance isn't an issue).

Re:It's just ARM heads

[jabjoe]

Economy of scale.

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:Itanium, from the same people that brought the

[gl4ss]

you forgot that you can sell crap big iron to banks for a wide profit, no need to keep the production lines online all year even.
it doesn't matter what the big iron is you see, as long as it's not the same as the clerk is using on desktop(or if it is, that it is at least named differently).

massively parallel machines are easy to build.. but ehm, linear speed is whats interesting, really. that's what people would want at home, so much more possibilities would be in that route than in parallel and less speed per unit..

gpu-farms already exist, if your problems parallel easily and are actually rather simple.

No They won't

[Anonymous Coward]

a) contractual penalties
b) the itanic it is sitting on a undersea mountain of cash anyway

Nothing ill-fated about itanium

[Eunuchswear]

It did exactly what it was supposed to, destroyed all the competition for i386.

Where is Alpha now? What happened to SGI?

Re:Nothing ill-fated about itanium

[TheRaven64]

SGI wasn't killed by Itanium. They continued to support MIPS chips - and still do - and never jumped on the Itanium bandwagon. They made two incredibly stupid mistakes:

The first was thinking that Windows NT 4 was the future of workstations. They devoted a lot of resources to making NT workstations instead of IRIX ones, but their machines couldn't really do anything that a cheap Dell couldn't do for a tenth the price. They tried to compete in a commodity market with bespoke parts.

Then, they made the mistake of assuming that the commodity market would never encroach on their bespoke market. Some of their engineers produced a design for a cut--down version of their graphics chips that could be sold as a PCI add-on for PCs. They turned it down, because the margins were too low. Those engineers left and founded a little startup called nVidia. Their former bosses were right: the margins were low, but the volumes were orders of magnitude higher, which made up for it. With nVidia selling 1000 chips for every one that SGI sold, they could get the per-unit costs low, devote a lot more money to R&D. Within a few generations their cheap commodity chips were faster than high-end SGI ones. SGI had the chance to own a large commodity market, but they mistakenly believed that if they didn't do it then no one would.

Re:Nothing ill-fated about itanium

[Eunuchswear]

SGI wasn't killed by Itanium. They continued to support MIPS chips - and still do - and never jumped on the Itanium bandwagon.

Ah. What's this?

http://en.wikipedia.org/wiki/Silicon_Graphics#Switch_to_Itanium

n 1998, SGI announced that future generations of its machines would be based not on their own MIPS processors, but the new “super-chip” from Intel, Itanium. Funding for its own high-end processors was reduced, and it was planned that the R10000 would be the last MIPS mainstream processor.

Yes, I was...

[RichiH]

...I honestly didn't know they still made the Itanium.

Eh?

[Viol8]

Segmentation on x86 is for 16 bit code so unless they're running old DOS programs I don't see how that can work on 32 or 64 bit memory address spaces.

Re:Eh?

[Anonymous Coward]

Not. 16-bit code is required to play with segments if it doesn't want to be limited to 64K of code and 64K of data. 32-bit code typically doesn't worry about segments because the operating system maps a single segment to a process's entire address space. So segments are still used in 32-bit code, you just don't notice. However, you are right that segments don't work in 64-bit mode.

Probably what happen

[C_Kode]

Probably what happen was Oracle said pay me million and millions of dollars or I'll stop development for Itanium. Intel said no and Leisure Suit Larry followed through with his threat.

IA64 is not x86

[supradave]

IA64 is not x86 (though it can do x86). That seems to be the problem people have with it, i.e. ignorance of what it is.

Benchmarks

[Chemisor]

Here are some benchmarks to prove it. Sparc gives 2-3 times less performance per core at much higher cost.

Instruction bloat

[Chemisor]

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

Yeah they do, but when you are writing for ARM, you have to replicate those complex interactions when you want them. ARM may have a simpler instruction set (for now; it has been increasing in complexity steadily, and frankly will soon be even harder to understand than x86), but it takes more instructions to do the same thing. x86-64 is great if you want to program in assembly. The instructions are very expressive and the whole set of them feels specifically designed for hand coding. You can write some really tight and small stuff in x86-64 assembly. ARM, on the other hand, is designed for a high-level compiler, which doesn't mind throwing more instructions at a problem. Result is bloated code that clogs your caches. I'd take x86-64 any day.

Re:Instruction bloat

[TheRaven64]

Yeah they do, but when you are writing for ARM, you have to replicate those complex interactions when you want them.

The key part of this is the 'when you want them' bit. 99% of the time, you don't. Take a look at the papers published by the VirtualPC for Mac team. They got a significant speedup in their emulator in a prototype by never generating these for some common cases and then reevaluating the operation lazily when the side effects were actually used.

With my compiler writer hat on, x86 is a horrible ISA to target, and horrible compared to ARM when you're coming from a language that isn't C (just pretty bad from C). For example, until x86-64, there was no sane addressing mode to use for PC-relative addressing, so all position-independent code needed to do an arithmetic operation and then a load / store. On ARM, this was just a PC-relative load/store (and often you could use the barrel shifter for the arithmetic part of array index computations too).

ARM may have a simpler instruction set (for now; it has been increasing in complexity steadily, and frankly will soon be even harder to understand than x86), but it takes more instructions to do the same thing.

ARM isn't much simpler, its just that its complexity is actually useful. The complex ARM instructions do things that are frequently useful. Complex x86 instructions do things like copy strings in a way that's slower than a loop.

You can write some really tight and small stuff in x86-64 assembly. ARM, on the other hand, is designed for a high-level compiler, which doesn't mind throwing more instructions at a problem. Result is bloated code that clogs your caches. I'd take x86-64 any day.

ARM code is typically smaller than x86 code, especially in Thumb-2 mode where it's often a lot smaller. You may be able to hand-tune the x86-64 code to be smaller, but I'd be willing to bet that a competent ARM assembly programmer can make his version even smaller.

Re:Instruction bloat

[jabjoe]

Not done any x86-64, but from a quick glance at the disassembler, it doesn't look that different..... ARM was design to be written by hand. It was not written for high-level compilers. Read/listen to what Sophie Wilson has to say on the subject. ARM came from the Acorn, a platform I cut my teeth on. On the Acorn platform, pretty much everything important was written in ARM by hand, and what wasn't was BBC BASIC with ARM for the hot spots. Since then, new instructions have been added, for things like processing multiple input on a single instruction, virtual memory, etc, but it's not like it suddenly has anything even close to mess of x86.

Itanium was a good idea

[nurb432]

But poorly managed/marketed. Even if something is better technology if its not properly marketed, no one will care..

Just like what happened to the iAPX 432.

ARM-heads, PowerPC heads, same difference

[pyrr]

I would just add to what you're saying, if RISC is so great, why is it that PC beige boxen smoked the pre-Intel Macs pretty convincingly? I recall some downright deceptive advertising on Apple's part, where they were trying to demonstrate the PowerPC's supposed superiority by comparing the bleeding-edge model to older, lower-clocked Pentium II processors rather than the best consumer-grade Pentium II in some RISC-biased benchmarks (it was an ad campaign they were running in about 2001 or thereabouts, most folks probably didn't go to the data to see what they were comparing). And of course, at that time, the Xeon line absolutely smoked them all.

Yeah, the PowerPC architecture was so vastly superior in its RISC-iness, that Apple abandoned it and started making Intel Macs (well, sure, IBM also wanted to take its processor line in a different direction, too). But in an Orwellian twist, the fanbois suddenly seemed to think that Macs had always been based on the vastly superior Intel x86, and the old, inferior PowerPC RISC processors that they had been hyping-up never existed.

So yeah, we've already gone through all that, I'm done with imagined superiority, I want to see a compelling, real-world demonstration of superiority before I'll jump on anybody's bandwagon. Such a demonstration must also include such things as stability and scalability. What is it capable of, what is its price point, how durable is it, and how compatible is it with the stuff most people need to run (i.e., desktop operating systems)? That's what matters. ARM isn't there, RISC in general isn't there, but most members of the x86 family are generally at least in the ballpark. ARM is great for certain things, but not even close to being good for many things, or even "most" things. Superiority only comes in one flavor, and that's what gets the job done and does it in the best way that the application requires.

Re:elitism

[Artemis3]

Good thing you are not the elitist...

Your heavy resentment seems to blind you to the fact that, developers ARE users, and they don't just use their own programs...

A basic windows domain can be setup using linux/samba in a manner of minutes. Leave your 15 year old with google to the task and he/she will probably solve it in a day without touching windows. Some distros are even turnkey like for a task like that.

The fact there is a cli and gui doesn't make something any more or less "friendly". It is not friendly needing to open 20 often unrelated windows, and navigate thru countless tabs and buttons only to end needing to go in the registry add a cryptic key to enable an option, which could be a simple line in a console, or edit a simple text file and restart service.

Windows didn't won because it was "friendly", you seem to forgot the competition had similar, if not better user interfaces and OS reliability back then.

So you think legacy is needed in the hardware? Tell me then, how did Apple went from Motorola to IBM, and then to Intel? Hey guess what, your ancient AoE game runs just fine in wine... And the older stuff runs great with dosbox; and that means, yes, NO WINDOWS.

ARM fail? Do you happen to know why Microsoft plans to release Windows 8 or whatever is called on that processor? Because if they don't, there is that "elitist" OS thingie that will steal their sales, yes, they suffered the pain with the advent of the linux netbook in 2007. They got so scared, they extended the lifetime of windows XP even after it was declared EoL.

The ARM processor can do a lot more with less power, it is more than suited for running desktop computing, in fact all current x86 processors are way overpowered for the office, becoming power hogs, and its starting to affect the datacenter as well.

There is no developers vs users, there is simply people doing things different than you do. Some develop, but all use. Feel free to do as you please, but don't blame it on others for not going your way.

Never forget, the internet is not built on windows...

Killer App?

[fuzznutz]

Your rant smacks of revisionist history. You discount the significance of the so-called killer app. You see, in the old days before Windows, there was Apple and CP/M for "big boy" personal computers. Then IBM came along and dropped the PC on the world. Along came VisiCalc, and next thing you know, the PC was the must have device. Every big change has been preceded by the "must have" technology. Apple is making a killing in the iPhone/Ipad/iPod market with just this strategy.

Windows has had an exceptionally long run in terms of the computer industry. There is a tipping point, however. You are unimaginative and delusional if you think that legacy Windows and x86 will continue on forever. Change in inevitable. It is just a matter of when. Once the "must have" tech exceeds the inertia of the "I wanna run my ten year old game on my brand new desktop" crowd, Windows will evolve to compete or die. And let's face facts. As of today, Windows is the main reason that x86 survives. The past is littered with the corpses of technology industry kings who thought that their installed base made them invulnerable to the next big "must have" technology.

Your rant against developers is just asinine. Developers DO control what you run if you want to run anything new. If you are contented with your Office 2000 forever, then good for you. But when the next killer app runs only on Android or IOS or whatever else might come, we won't cry for you when developers jump ship from Windows and leave you high and dry with all your legacy software. You can commiserate with all the CP/M, BeOS, Palm, OS/2, and Amiga people.

Re:elitism

[hairyfeet]

Riiiight. Bullshit bullshit ANNNND bullshit, to quote Mel Brooks. The Linux FOSSies have been screaming "The Internet doesn't run Windows!" for a decade now, and guess what? They are still below the margin for error and are going nowhere fast. Why? Because their product is shit, and free shit is STILL shit. What happens to Linux in 6 months? Oh yeah look what happened I pushed the "break Linux NOW button" aka the update button and now half my damned drivers don't work and the ONLY way to fix it is hours trawling forums and CLI hell. Thanks Linus you giant douchebag for refusing to allow a stable ABI because it means you couldn't break shit at will. Asshole.

And the simple fact is it has been tried again and again and AGAIN and you know what? The public says "hey my stuff won't run on this!" and shitcans it. Just last Xmas the local stores got a load of ARM netbooks in, selling at the low price of $125 where are they now? I can pick them up all day on craigslist for less than $50 each, nobody wants it. Why? Does the Internet not work on them? The Internet works fine, it is all the x86 programs people want that don't work and therefor shitcanned it.

Look believe what you want, I've been around this dance before so I'll sit back and laugh. I watched the "future is the thin client!" dance (now being rehashed with "the future is the cloud!") and I watched the Apple CPU two step (BTW the reason Apple can get away with that shit is Macheads worship Steve as their Lord and Savior. I knew guys that bought mid 90s Macs, overpaying even though they were shit because they were Macs so if that isn't devotion I don't know what is) but you are simply forgetting we are talking over a billion Windows users which equals tens of billions of apps that are "must have" for these people to work and play. They don't go? Your device gets shitcanned.

And as for Win 8? Don't forget MSFT did this very same thing when it came to WinNT, which ran on every major arch there was. What happened? It is simple nobody bought it because it wouldn't run their apps and the same thing will happen again. ARM has its niche because cell devices like phones and pads are disposable, full stop. Nobody cares if the apps continue to run because the toss it in the garbage and buy a new one. But when gas hits $6 a gallon you're gonna see ARM dry up and blow away like a fart in the breeze because people will begin demanding devices that actually last, which means they'll begin wanting to keep their apps.

ARM has ZERO backwards compatibility, the infrastructure is a fragmented mess, meanwhile both AMD and Intel are coming out with sub 8w chips that do full 1080p and will run everything you have now and thanks to the Apple iSliver battery conditioning people to always carry a charger with them battery life won't mean shit. The writing is on the wall, hell bookmark this post and come back in 5 years to see how much I've posted comes true. those of us who have been doing this for decades has seen this dance over and over.

If MSFT would have followed up Vista with Vista II I'd have been right there with you, but getting spanked seemed to wake them up. The new Win 7 runs great on just 1Gb of RAM and Starter runs great even on Atom. The new chips will kick serious ass and ARM will be left to cells and pads, where their one advantage (low power above all) will let them hang onto their niche. Everywhere else? It will be cheap ULV X86 chips as far as the eye can see.

It's name was Poulson.

[csb]

It's name was Poulson.
It's name was Poulson.
It's name was --- oh hello again sir.