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?"

Comments

Re:Of course it means the end.

[the linux geek]

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.

Re:Doubt it.

[dave562]

The WSJ mentioned that Intel was porting a lot of the Itanium specific fault tolerance features over to the Xeons.

Re:DEC Alpha?

[mihalis]

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

Re:Still supported on real OSes like Linux and HPU

[Macka]

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.

Re:Probably not

[cbhacking]

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.

Re:Not Very Comparable

[cbhacking]

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.

Re:No one can stop the x86 train, not even Intel.

[TheRaven64]

Not yet, no. Unlike x86, the ARM architecture is quite clean. When you go from x86 to x86-64, you get more registers.

• You go from 8 registers with a load of instructions that require specific registers to be used as operands to 16 general purpose registers. ARM has 33 GPRs already.
• You get to compile code assuming that it has SSE, rather than the old x87 FPU (which is really hard to generate efficient code for due to its stack-like-but-not-quite design). ARM already has a sane FPU design.
• You get to guarantee the existence of fast system call instructions. ARM already has fast interrupts.
• You get an extra addressing mode that makes position-independent code much faster. ARM already has lots of useful addressing modes.
• You get page-level readable-but-not-executable support. ARM already has this (actually, so do most x86 recent chips).
• You remove a lot of cruft. ARM already has Thumb and Thumb-2 instruction sets that let you produce very dense code (16-bit instructions) for good instruction cache usage by eliminating the less-frequently-used instructions.

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