Thursday, November 2nd 2023

Intel Itanium Reaches End of the Road with Linux Kernel Stopping Updates

Today marks the end of support for Itanium's IA-64 architecture in the Linux kernel's 6.7 update—a significant milestone in the winding-down saga of Intel Itanium. Itanium, initially Intel's ambitious venture into 64-bit computing, faced challenges and struggled throughout its existence. It was jointly developed by Intel and HP but encountered delays and lacked compatibility with x86 software, a significant obstacle to its adoption. When AMD introduced x86-64 (AMD64) for its Opteron CPUs, which could run x86 software natively, Intel was compelled to update Xeon, based on x86-64 technology, leaving Itanium to fade into the background.

Despite ongoing efforts to sustain Itanium, it no longer received annual CPU product updates, and the last update came in 2017. The removal of IA-64 support in the Linux kernel will have a substantial impact since Linux is an essential operating system for Itanium CPUs. Without ongoing updates, the usability of Itanium servers will inevitably decline, pushing the (few) remaining Itanium users to migrate to alternative solutions, which are most likely looking to modernize their product stack.
Source: Phoronix
Add your own comment

33 Comments on Intel Itanium Reaches End of the Road with Linux Kernel Stopping Updates

#1
phanbuey
They tried to do too much all at once, seems like the intel way.
Posted on Reply
#2
thesmokingman
I can't imagine how much money wasted to try to keep this pos going.
Posted on Reply
#3
Solaris17
Super Dainty Moderator
thesmokingmanI can't imagine how much money wasted to try to keep this pos going.
none. Companies had to pay for this support.
Posted on Reply
#4
Fouquin
AleksandarKWhen AMD introduced x86-64 (AMD64) for its Opteron CPUs, which could run x86 software natively, Intel was compelled to develop a new line, Xeon, based on x86-64 technology, leaving Itanium to fade into the background.
What? This is objectively false. Intel introduced the Xeon brand in 1998 well in advance of both Itanium and AMD64.
Posted on Reply
#5
AleksandarK
News Editor
FouquinWhat? This is objectively false. Intel introduced the Xeon brand in 1998 well in advance of both Itanium and AMD64.
Fixed the sentence!
Posted on Reply
#6
Vya Domus
Crazy this survived for so long.
Posted on Reply
#7
Canned Noodles
I wonder who is still running anything on those systems
Posted on Reply
#8
Solaris17
Super Dainty Moderator
Canned NoodlesI wonder who is still running anything on those systems
HP used them in HPC systems and started replacing there fleet in 2021 iirc. They pretty much held the last contract with Intel for it.
Posted on Reply
#9
natr0n
Ive never seen a Yt video about gaming on this ancient platform.
Posted on Reply
#10
Vya Domus
natr0nIve never seen a Yt video about gaming on this ancient platform.
Because the games wont run, different architecture, they either have to be compiled for IA64 or use some sort of emulation layer, I doubt anyone ever bothered to do that.
Posted on Reply
#11
thesmokingman
Vya DomusBecause the games wont run, different architecture, they either have to be compiled for IA64 or use some sort of emulation layer, I doubt anyone ever bothered to do that.
It's not just a different architecture, they literally made closed so no backward compatibility at all. The market was like yea ok bro.
Posted on Reply
#12
ScaLibBDP
FouquinWhat? This is objectively false. Intel introduced the Xeon brand in 1998 well in advance of both Itanium and AMD64.
That is correct that Intel introduced Xeon architecture in 1998. However, all Xeon-like CPUs released before June 2004 were 32-bit. First 64-bit Xeon-like CPU ( Code name Nocona ) was released in June 2004.

Note 1:
I worked on a project related to porting a scientific library to Intel Itanium IA-64 Architecture. Unfortunately, the project was cancelled after Intel announced Itanium processors would be discontinued.

Note 2:
There was a question "Who is still running some software on it?". It could be R&D Labs at Universities, Supercomputing Centers, like TACC.

Note 3:
Even older Intel CPUs significantly outperform Intel Itanium CPUs. Here are two sets of Intel CPUs ( Intel Itanium vs. Intel Xeon Phi ) for comparison:

// Intel Itanium Processors - Processing Power

www.intel.com/content/dam/support/us/en/documents/processors/APP-for-Intel-Itanium-Processors.pdf

9010 12.80 GFLOPs
9015 11.20 GFLOPs
9020 11.36 GFLOPs
9030 12.80 GFLOPs
9040 12.80 GFLOPs
9050 12.80 GFLOPs
9110N 12.80 GFLOPs
9120N 11.36 GFLOPs
9130M 13.28 GFLOPs
9140M 13.28 GFLOPs
9140N 12.80 GFLOPs
9150M 13.28 GFLOPs
9150N 12.80 GFLOPs
9152M 13.28 GFLOPs
9310 12.80 GFLOPs
9320 21.33 GFLOPs
9330 23.36 GFLOPs
9340 25.60 GFLOPs
9350 27.68 GFLOPs
9520 27.68 GFLOPs
9540 68.16 GFLOPs
9550 38.40 GFLOPs
9560 80.96 GFLOPs
9720 27.68 GFLOPs
9740 68.16 GFLOPs
9750 40.48 GFLOPs
9760 85.12 GFLOPs

// Intel Xeon Phi Processors - Processing Power

www.intel.com/content/dam/support/us/en/documents/processors/APP-for-Intel-Xeon-Phi-Processors.pdf

7235 1331.00 GFLOPs
7255 1197.00 GFLOPs
7285 1414.00 GFLOPs
7295 1728.00 GFLOPs
7210 2662.00 GFLOPs
7230 2662.00 GFLOPs
7250 3046.00 GFLOPs
7290 3456.00 GFLOPs
7210F 2662.00 GFLOPs
7230F 2662.00 GFLOPs
7250F 3046.00 GFLOPs
7290F 3456.00 GFLOPs
Posted on Reply
#13
thesmokingman
It's ironic that 64bit XEON were compelled to be built on AMD64 lolzers.
Posted on Reply
#14
ScaLibBDP
thesmokingmanIt's ironic that 64bit XEON were compelled to be built on AMD64 lolzers.
Everybody should say "Thank you, AMD, for x86-64 Extension"...
Posted on Reply
#15
thesmokingman
ScaLibBDPEverybody should say "Thank you, AMD, for x86-64 Extension"...
Can you imagine what the computing landscape would have looked like if Intel and HP got away with it?
Posted on Reply
#16
unwind-protect
phanbueyThey tried to do too much all at once, seems like the intel way.
They believed in magic compilers that did not exist and still do not exist.

SIMD is nice but you still don't get much of it from high-level or portable programming languages.
Posted on Reply
#17
Wirko
Did Linux ever drop support for an entire processor architecture before?
Posted on Reply
#18
ScaLibBDP
unwind-protectThey believed in magic compilers that did not exist and still do not exist.
We used two versions of cross-compilers for Itanium architecture, from Intel and Microsoft, on Windows 7 Professional 64-bit and Windows 2000 Professional 32-bit.

No any problems with our source codes. The problem was with hardware because it was Too Expensive and performance was so-so ( see my previous post ).

Here are, for example, outputs from my Software Development Environment for Itanium:
...
Setting environment for using Microsoft Visual Studio 2005 x86 tools.
Targeting Windows Server 2003 IA64 ( Itanium 64-bit ) RETAIL
Intel(R) C++ Compiler Professional for applications running on IA-64, Ver 11.0.075
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
...
C:\>cl.exe /?
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.39 for IA-64
Copyright (C) Microsoft Corporation. All rights reserved.
...
C:\>icl.exe /?
Intel(R) C++ Compiler Professional for applications running on IA-64, Version 11.0
Build 20090609 Package ID: w_cproc_p_11.0.075
...
Posted on Reply
#19
Minus Infinity
Should have always been named the iTanic. What a debacle. The real tragedy is what happened to DEC.
Posted on Reply
#20
Ruru
S.T.A.R.S.
Vya DomusBecause the games wont run, different architecture, they either have to be compiled for IA64 or use some sort of emulation layer, I doubt anyone ever bothered to do that.
Youtube is full of "for science" videos what it comes to older tech. :D
Posted on Reply
#21
ymdhis
Minus InfinityShould have always been named the iTanic. What a debacle. The real tragedy is what happened to DEC.
Itanic was coined on usenet literally within hours after its announcement.
Posted on Reply
#22
unwind-protect
ScaLibBDPWe used two versions of cross-compilers for Itanium architecture, from Intel and Microsoft, on Windows 7 Professional 64-bit and Windows 2000 Professional 32-bit.

No any problems with our source codes. The problem was with hardware because it was Too Expensive and performance was so-so ( see my previous post ).

Here are, for example, outputs from my Software Development Environment for Itanium:
...
Setting environment for using Microsoft Visual Studio 2005 x86 tools.
Targeting Windows Server 2003 IA64 ( Itanium 64-bit ) RETAIL
Intel(R) C++ Compiler Professional for applications running on IA-64, Ver 11.0.075
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
...
C:\>cl.exe /?
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.39 for IA-64
Copyright (C) Microsoft Corporation. All rights reserved.
...
C:\>icl.exe /?
Intel(R) C++ Compiler Professional for applications running on IA-64, Version 11.0
Build 20090609 Package ID: w_cproc_p_11.0.075
...
And did that automatically do the SIMD scheduling that was the only thing that could have made Itanium fast?
Posted on Reply
#23
L'Eliminateur
i doubt that even with CURRENT state of the art compilers(mainly.. GCC at this point) you could extract enough parallelism to make a VLIW arch like shitanium work.

And as you say, the problem was not only X86 compatibility(which was utter shit), is that even with native code it was not particularly fast, it was the wrong product at the wrong time.

maybe in a fantastic future where we have AI compilers or runtime AI compilers that change the compilation according to the workflow or some shit like that it "could" work....

and yes, the real tragedy in all this was DEC, Intel should've ditched shitanium and kept developing the ALPHA which was already 64bit and blazing fast and had already known software for a long time, i mean if you're going to ditch x86 might as well go for alpha and maybe develop some kind of hardware emulation/translation layer
Posted on Reply
#25
ScaLibBDP
unwind-protectAnd did that automatically do the SIMD scheduling that was the only thing that could have made Itanium fast?
Yes. For Intel for IA-64 compiler default options set to create as fastest as possible binaries. For example:
...
/O2 optimize for maximum speed (DEFAULT)
...
/Qvec[-] enables(DEFAULT)/disables vectorization
...

OpenMP was the easiest way to enable parallelization ( in our codes almost all for-loops have #pragma omp ... directives ):
...
/Qopenmp enable the compiler to generate multi-threaded code based on the OpenMP* directives
...

Auto-Parallelization was also available (!):
...
/Qparallel enable the auto-parallelizer to generate multi-threaded code for loops that can be safely executed in parallel
...

SIMD-like features for explicit application of vectorization was also available from fvec.h and dvec.h:
...
const union
{
int i[4];
__m128d m;
} __f64vec2_abs_mask_cheat = {0xffffffff, 0x7fffffff, 0xffffffff, 0x7fffffff};

#define _f64vec2_abs_mask ((F64vec2)__f64vec2_abs_mask_cheat.m)

/* EMM Functionality Intrinsics */

class I8vec16; /* 16 elements, each element a signed or unsigned char data type */
class Is8vec16; /* 16 elements, each element a signed char data type */
class Iu8vec16; /* 16 elements, each element an unsigned char data type */
class I16vec8; /* 8 elements, each element a signed or unsigned short */
class Is16vec8; /* 8 elements, each element a signed short */
class Iu16vec8; /* 8 elements, each element an unsigned short */
class I32vec4; /* 4 elements, each element a signed or unsigned long */
class Is32vec4; /* 4 elements, each element a signed long */
class Iu32vec4; /* 4 elements, each element a unsigned long */
class I64vec2; /* 2 element, each a __m64 data type */
class I128vec1; /* 1 element, a __m128i data type */
...
Posted on Reply
Add your own comment
Nov 17th, 2024 15:15 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts