Slashdot Mirror
Microsoft Announces End of the Line For Itanium Support
WrongSizeGlass writes "Ars Technica is reporting that Microsoft has announced on its Windows Server blog the end of its support for Itanium. 'Windows Server 2008 R2, SQL Server 2008 R2, and Visual Studio 2010 will represent the last versions to support Intel's Itanium architecture.' Does this mean the end of Itanium? Will it be missed, or was it destined to be another DEC Alpha waiting for its last sunset?"
How could anyone possibly have any use for servers that don't run Windows?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It would appear that the good ship Itanic has struck an MS Iceberg 2010 Datacenter Edition R2!
Seriously, though: is this an admission by Microsoft that HP-UX is(somehow) hanging on at the high end, despite HP's every attempt to mismanage it, or (more likely) is this a consequence of the fact that, at this point, there is nothing Itanium can do that Intel couldn't do better and cheaper just by bolting some extra cache and a few extra Itanium features onto Xeons?
With Alpha finally gone for good, its job is done and it can now sail off into the West.
Lacking <sarcasm> tags,
I am incredibly offended that you would compare this bloated, brute-force, abomination of a chip to the incredibly well designed, elegant, and efficient Alpha (may it rest in peace).
The DEC Alpha was a much better chip than the Intel Itanium; and not just in the way that Johnny Mathis is way better than Diet Pepsi.
The DEC Alpha was a brilliant RISC processor that could outrun a closet full of x86 chips of the same era (or even the era after). The DEC Alpha was sold by a hardware company that distributed their own Unix-derived OS for it that had the proper compilers ready to go as soon as the system was booted. The Itanium, on the other hand, was an odd attempt by Intel to make a 64bit CPU that could - mostly - run 32bit code as well. Unfortunately by the time the Itanium was released the Intel-Microsoft pairing was well established for most consumers and people wanted it to run Windows Server; which it didn't do particularly well.
So the Itanium may end up killed by the combined factors of lack of a market, lack of consumer interest, lack of consumer knowledge, and poor deployment. The DEC Alpha, on the other hand, was killed by upper level management who didn't seem to know what they had.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Does this mean the end of Itanium? Will it be missed, or was it destined to be another DEC Alpha waiting for its last sunset?
Kinda funny to make that comparison since the Alpha was killed to enable the Itanium. (Long story involving HP making a deal with Intel to hand over the last of PA-RISC/Itanium processor development to Intel and DEC killing Alpha at the same time to clear out the market since HP was in the process of purchasing DEC/Compaq, although the acquisition was not yet public at the time of the cpucide).
But I doubt its the end of Itanium. Itanium models have things that even the latest Xeons don't in terms of RAS. Most customers don't care about the level of fault tolerance and reliability, but the ones who can't migrate to linux (or Windows) because they are dependent on features of more proprietary OSes like Tandem (now HP) NonStop do need Itanium, and their software is unlikely to be ported to x86 anytime soon (it took at roughly 4 years to get NonStop ported to Itanium to begin with).
When information is power, privacy is freedom.
The only Itanium servers I encounter regularly run OpenVMS in order to host the popular OM stock exchange platform. OM-based stock exchanges (ASX, HKFE, OMX, SGX, IDEM) all seem to be a hell of a lot more stable than the .NET-based Tradelect/Infolect system used on LSE for the last few years. I don't know why anyone would actually want to run Windows on Itanium.
Windows on IA-64 can't be dying until Netcraft confirms it!
Welcome to the Panopticon. Used to be a prison, now it's your home.
They all get outmoded.
No one ever had to evacuate a city because the solar panels broke!
No one can stop the x86 train, not even Intel.
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Debian 27 plans to drop support.
Itanium has not been worth it in terms of price/performance for a while
Actually, in many categories, it does. Depends on the work to be done. For example, HP Integrity Superdome with HP/UX leads in price / performance and performance running TCP-H on 10 or 30TB Oracle database. Some on numerical benchmarks that are heavily SMP.
I don't like the Itanium, but certain database and numerical workloads it still kicks everyone else's butts.
Microsoft has had a strict policy since the dawn of Windows that Windows be built for at least 2 processor architectures at all times. They really worried about i386-isms creeping into the kernel. It pretty much doesn't matter what 2 you choose, as long as it's more than one (and they're somewhat different), it keeps the kernel devs honest. I wonder what they're doing now: perhaps they just decided that i386 and "amd64" are different enough to serve their purpose.
Socialism: a lie told by totalitarians and believed by fools.
IBM's Power chips make up the main processor(s) for the Xbox360 and PS3, so are you saying that the Itanium will end up in multiple consoles found in millions of homes?
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
The other thing is, keep a full build internally.
The rumor mill says that Microsoft has current versions of Windows built for ARM internally... sorta like how Apple kept x86 builds of Mac OS X internally the whole time.
Oh come on. It's really disingenuous to be quoting that kind of shit. Have you ever taken a really close look at the kind of hardware the vendors use to get these benchmark numbers? Database app benchmarks are almost always very sensitive to I/O, and these kinds of numbers are usually generated by systems that have their I/O card slots max'd out, with several hundred (if not thousands) of small high speed disks behind them. The cost of these solutions in real life would be crippling. Vendor quoted benchmarks should usually be taken with a generous pinch of salt.
This is a response to my own post. Sometimes after uncorking a minor screed, I note to myself "that was more obnoxious than normal" and then my subconscious goes "ding!" and I get what's grinding me.
The secret of x86 longevity is to have been so coyote-ugly that it turns into pablum the brain of any x86-hater who tries to make a chip to rid the planet of the scourge once and for all.
For three decades right-thinking chip designers have *wanted* x86 to prove as bad in reality as ugliness ought to dictate.
Instead of having a balanced perspective on beauty, the x86-haters succumb to the rule of thumb that the less like x86, the better. And almost always, that lead to a mistake, because x86 was never in fact rotten to the gore. You need a big design team, and it bleeds heat, but all other respects, it proved salvageable over and over and over again.
On the empirical evidence, high standards of beauty in CPU design are overrated. Instead, we should have been employing high standards of pragmatic compromise.
If any design team had aimed merely for "a hell of lot less ugly", instead of becoming mired in some beauty-driven conceptual over-reaction, maybe x86 might have died already.
Maybe instruction sets aren't meant to be beautiful. Of course, viewed that way, this is an age-old debate.
The Rise of ``Worse is Better''
Empirically, x86 won.
The lingering question is this: is less worse less better, or was there a way out, and all the beauty mongers failed to find it?
Just to keep this clear: you're talking about NT (which wasn't even called "Windows NT" initially, internally). NT is almost entirely written in C, and the few architecture-specific parts are abstracted from the core codebase and typically present in assembly modules which are maintained for multiple architectures and which the compiler automatically uses the appropriate one for the current build. There's some use of inline assembly or specifics of x86, but it's all behind #if blocks, with the equivalent checks for other CPU architectures. Overall, NT has been ported to at least 5 architectures that I know of - x86 (32-bit), x64, ia64 (Itanium), PPC, and DEC Alpha. If MS wanted to, it would be possible to port it to ARM, MIPS, SPARC, or almost any other reasonably modern architecture of at least 32 bits.
By comparison, Win9x has a ton of assembly code that enabled it to run fast even on low-end machines, keeping the system requirements down (and making it attractive to home users back in the days before consumer hardware caught up with the demands of NT). Of course, use of assembly like this has downsides - 9x was badly unstable, and completely non-portable. It only ever ran on x86, and I'm not even sure it made much use of the features found in any version after the i386.
There's no place I could be, since I've found Serenity...
Last time I was playing with it (caliper/HP-UX), it was doing up to around 1 instruction per cycle on average. Not very impressive but also not very bad either. It was three years ago, so I doubt that compilers would improve dramatically since then. And it has about half a clock speed Xeons have.
Now, since we have Nehalem EX and similiar monsters available, there is not much left on performance/scalability front for all those RISC designs, no matter how cool those designs are. The only thing keeping them alive is their hard-to-break-big-iron designs and hard-to-break-big-iron (system) software. Vendors might struggle to port these things onto now conventional x86_64 designs as they risk losing significant income stream doing so. But in the long run most of these things will be dead or become niches. The only area RISC will still shine are energy constrained environments (ARM?) and maybe some manycore designs, like some forms of GPUs evolving in this direction. In other words, the original area where RISC thingies started.
Note that I'm not trashing RISC here - this was a pretty neat idea. It's just history showing a bitter sense of humor: memory bandwidth is now a bottleneck and x86 code is known to be compact.
Marathon Technology provides a hypervisor that gives the same effect with commodity x86 crap: you run two nodes in parallel, they are kept perfectly in sync, and if either of them fails then the other takes over. This same functionality is now in the main Xen tree and will be released as part of Xen 4. The overhead of the Itanium version is probably lower, but I doubt it's lower by enough of a margin to make it cheaper.
I am TheRaven on Soylent News
Windows 2008 Server will not boot on a x86-32 processor. The fact that, after install, you can then install an optional x86-32 virtual machine is beside the point.
Vintage computer games and RPG books available. Email me if you're interested.