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?"
Exactly. Approximately 85% of Itanium servers are running HP-UX or OpenVMS. Windows and Linux are roughly split on the remaining 15%. Itanium faces challenges, but they're from POWER and SPARC, not from Microosoft killing Windows.
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.
The WSJ mentioned that Intel was porting a lot of the Itanium specific fault tolerance features over to the Xeons.
Yep. One of the best remaining reasons for the continued existence of Itanium is the HP NonStop servers, linear descendants of the Tandem NonStop mainframes. HP had Intel add features to the Itanium chips that would allow them to do some of the processor pairing tricks that were used in Tandem mainframes. I have no idea how hard it would be to retrofit an equivalent feature into the x86-64 design, but that's one of the few reasons for people to still want to buy Itaniums.
The short version is that in-order architectures only perform well on workloads where the memory access pattern and the branch pattern are predictable at compile time. Unfortunately, almost all of the things that people do with computers nowadays are exactly the opposite: neither pattern is predictable at compile time, which means the compiler cannot hide the latencies, so you *must* have an out-of-order architecture to get the speeds we expect nowadays. Both Alpha and Itanium were in-order, but Alpha was a classic RISC so it could have been made out-of-order without too much trouble. Itanium, however, was a VLIW, and it is enormously harder to implement an out-of-order VLIW.
Itanium also had features (like the NaT bits and the predicate registers) that were supposed to help compilers squeeze more speed out of unpredictable code, but in practice it turned out that they were very hard for compilers to take advantage of, and even when they helped, they would wind up wasting resources on instructions fetched, decoded, executed, and then the results discarded -- so much that they didn't actually translate to better time-to-completion. Which is all you really care about in the end.
In-order VLIW does still rule for DSP-type workloads; this is why your graphics card is so much faster than your CPU at doing the things that it does. The future probably looks a lot like the Cell -- some out-of-order cores to run the OS and do the general-purpose computation, some in-order DSPs to be tasked with the crypto or the 3D rendering or the video decode.
...Both Alpha and Itanium were in-order...
IIRC the Alpha 21264 was out of order actually, see http://courses.ece.illinois.edu/ece512/Papers/21264.pdf
Compaq's upper level management's arguments about Itanium's inevitability in the marketplace and economies of scale are a prime example of how you should never let management make decisions of real consequence. I listened to meetings at Compaq where not a single engineer in the crowd agreed with management, but there was nothing they could do. Everyone knew that the game was over simply because a bunch of morons with MBAs thought Intel was unbeatable and they wanted to give up.
We couldn't understand it until much later, when it turned out to be obvious that they wanted to kill Alpha so they could eventually merge with HP. Another move done for purely political reasons, not business or technology reasons.
HP on the other hand, probably knew that Alpha was a decent chip, but figured they could reap the benefits of having Intel taking over most of the Alpha engineers. Tru64 was successfully ported to Itanium, and then promptly killed. Because it wasn't HPs technology, they had no interest. They also killed the TruCluster product for political reasons, and let the technology disappear. It was all a big tragedy.
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.
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...
The POSIX NT subsystem (and Interix, the user-space software that runs in the subsystem) have existed for a very long time, possibly all the way back to pre NT 4. The NT kernel doesn't actually use Win32 (or Win16, DOS, or Win64) system calls; it uses NT system calls,w hich are a superset of the functionality in all of those, plus the functionality required for OS/2 and POSIX. For example, the NTCreateFile system call not only implements the Win32 CreateFile system call (as seen in Win9x) but also the OpenFile system call (Win16) and the open system call (POSIX). For each API that NT supports, there is a user-mode DLL that translates the API-specific system calls (such as open(2)) to NT system calls (such as NTCreateFile()). These are then passed to ntdll.dll, which executes the actual system call (invoking ring-0 kernel code).
The OS/2 subsystem was discontinued years ago, but the POSIX one is still supported. From XP forward, it's been possible to enable the POSIX subsystem and download pre-compiled libraries, shells, utilities, headers, build toolchain (optionally using GCC or MSVC), manpages, and so forth to produce a working, if somewhat bare-bones, UNIX-like environment. Initially called OpenNT and now known as Interix, various third parties have provided additional functionality such as package managers (apt, portage, pkgsrc, or one specifically for Interix from http://suacommunity.com/ ), additional shells, libraries, utilities, X servers, and more.
There's no place I could be, since I've found Serenity...
Just as a point of fact, DEC did not at all blow-off the x86 market even while they were flailing away on Alpha. They were the #3 commodity server vendor when Compaq (#1) bought them, ahead of both IBM and HP. (Personally speaking, Digital had some serious credibility with us PC guys.)
Furthermore, Compaq cited Digital's services group's expertise with Wintel as one the main reasons they bought the company. I would say of all the old minicomputer companies, Digital did the best job of adapting as anyone. Shame they were absorbed into a brand that was best known for cheap-ass Best Buy PCs. (But still #1 in the server market.)
Business. Numbers. Money. People. Computer World.
You also get more address space and bigger registers. Bigger registers are not such an issue with ARM. If you are using 64-bit operands, you have to split them between two registers, but that still leaves you with as many 64-bit GPRs as x86-64 has.
What about a bigger address space? This is really two issues: the physical and virtual address space. The physical address space is the amount of real memory the processor can access. Current ARM systems ship with 64-256MB of RAM. I think there may be a few with 512MB, but they're quite rare. Low power DDR is a lot more expensive than desktop / laptop RAM so these numbers are going to stay lower than laptop and desktop versions. Obviously, people will eventually want handhelds with more than 4GB of RAM, but it probably won't happen for a little while.
Note, however, that things like PAE on x86 allow you to access more than 4GB of physical address space. All that you need to do is extend the page tables slightly. On post-Pentium x86 chips, the page tables can map from a 32-bit virtual address space to a 36-bit physical one. This means that you can access 64GB of physical memory, but individual processes are limited to 4GB (unless they do some ugly things). This kind of thing is much easier for ARM because, unlike x86, the ARM architecture does not guarantee backwards compatibility in the privileged instruction set. They could quite easily extend the physical address space without changing the unprivileged instruction set, so you'd need to modify the kernel but no userspace stuff. I won't say 64GB ought to be enough for anyone, but a handheld with more than 64GB won't be affordable for many people for several years.
That leaves the virtual address space. I'm currently running a 64-bit OS on a 64-bit CPU and looking at my running processes, the biggest one is using around 750MB of virtual address space. the largest I've seen on this machine is around 1.2GB. That was a web browser, and there is no real reason why it should be using that much address space: for security, I'd rather that it ran more processes, isolating each site into a separate instance. During my PhD I did a lot of stuff that involved much larger processes, but I don't imagine ray tracing large volume data sets on an ARM machine any time soon.
That's not to say that there aren't things that benefit from a larger virtual address space. If you're doing video editing, for example, it makes life a lot simpler for the programmer if you can just mmap() the raw data files, which, at around 10GB/hour, can easily consume 100GB of virtual address space for a medium sized project. Of course, you can just stream the data as it's required. This involves some extra copying, but it's not a huge amount of effort, and most existing code does this anyway.
If your process doesn't need more than 4GB of virtual address space, then there's a significant
I am TheRaven on Soylent News
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.
NT was actually available for MIPS, ARC-based Little Endian MIPS boxes like the MIPS Magnum to be precise.