Question RIP Itanic

[NTMBK]

https://www.anandtech.com/show/1392...nium-9700-kittson-processor-the-last-itaniums

Intel's finally closing the book on a very embarrassing chapter in their history.

 

[TheGiant]

did it have any advantages over current xeon or epic lineup ?

 

[NostaSeronx]

RISC-V killed Itanium.

HPE India and Intel India is looking upon IIT-Madras' Shakti H-class processors.

did it have any advantages over current xeon or epic lineup ?

No.

 

[BigDaveX]

did it have any advantages over current xeon or epic lineup ?

The only time Itanium ever held any serious advantages over the Xeon line-up was from roughly 2002 (with the release of Itanium 2) to 2006, and even then a lot of that was due to the Netburst-based Xeons mostly being absolute garbage. The Core 2-based Xeons eliminated most of those advantages, and soon as the Nehalem-based Xeons showed up, any reason to own an Itanium was all but snuffed out.

 

[NTMBK]

The only time Itanium ever held any serious advantages over the Xeon line-up was from roughly 2002 (with the release of Itanium 2) to 2006, and even then a lot of that was due to the Netburst-based Xeons mostly being absolute garbage. The Core 2-based Xeons eliminated most of those advantages, and soon as the Nehalem-based Xeons showed up, any reason to own an Itanium was all but snuffed out.

Itanium still had a lot of RAS features, not sure if all of those have made it into the top-end Xeons yet?

 

[SarahKerrigan]

The only time Itanium ever held any serious advantages over the Xeon line-up was from roughly 2002 (with the release of Itanium 2) to 2006, and even then a lot of that was due to the Netburst-based Xeons mostly being absolute garbage. The Core 2-based Xeons eliminated most of those advantages, and soon as the Nehalem-based Xeons showed up, any reason to own an Itanium was all but snuffed out.

IPF could still trade blows with Core2 on technical compute workloads, due to a combination of 4 LSUs, an extremely aggressive cache/memory subsystem, and a pair of very large FMA units.

Note that during that 2002-2006 period (actually a little longer) IPF was also beating SPEC numbers for Opteron, especially but not exclusively on the FP side. Do you consider K8 to be absolute garbage?

 

[Tuna-Fish]

RISC-V killed Itanium.

Lolnope. Itanium was dead long before RISC-V was created. This announcement came on a predefined schedule, set by the contracts Intel signed long ago about providing chips to long tail customers.

 

[Nothingness]

Lolnope. Itanium was dead long before RISC-V was created. This announcement came on a predefined schedule, set by the contracts Intel signed long ago about providing chips to long tail customers.

And anyway at the moment RISC-V cores are just toys. It will take years before we get any high perf RISC-V CPU... that is unless it collapses due to ISA fragmentation.

 

[SarahKerrigan]

Lolnope. Itanium was dead long before RISC-V was created. This announcement came on a predefined schedule, set by the contracts Intel signed long ago about providing chips to long tail customers.

Indeed. IPF's fate was sealed when Kittson-22 was canned in January 2013, when RISC-V was little known - and it had been circling the drain since about 2010. (Tukwila did not compare favorably to Power7 or Nehalem-EX.)

 

[Topweasel]

Honestly while Intel hoped they could maintain the PIV status quo till Itanium was fully ready to handle most server workloads. Itanium was circling the drain the second Intel adopted EMT-64. With Itanium being the only Intel solution that could support large memory sizes Intel could herd people to adopting and converting to Itanium. But as soon as Intel launched their first PIV with EMT-64, 90% of the server needing world basically dropped any plans to adopt it. From their it just became a contractual obligation for continual advancement for people who already adopted it and their requirements for HP who scrapped two major advanced server CPU product lines to work with Intel on Itanium.

 

[SarahKerrigan]

Honestly while Intel hoped they could maintain the PIV status quo till Itanium was fully ready to handle most server workloads. Itanium was circling the drain the second Intel adopted EMT-64. With Itanium being the only Intel solution that could support large memory sizes Intel could herd people to adopting and converting to Itanium. But as soon as Intel launched their first PIV with EMT-64, 90% of the server needing world basically dropped any plans to adopt it. From their it just became a contractual obligation for continual advancement for people who already adopted it and their requirements for HP who scrapped two major advanced server CPU product lines to work with Intel on Itanium.

You have an interesting perception of IPF history.

IPF originated at HP in the late 1980s and early 1990s as PA-WideWord, intended from the beginning as an advanced successor to PA-RISC. Intel cancelled their own 64-bit RISC project (IAX) in 1994 to join HP's project. By that time, the major bones of what became IPF were already in place (obviously excluding x86 compatibility.)

 

[Topweasel]

You have an interesting perception of IPF history.

IPF originated at HP in the late 1980s and early 1990s as PA-WideWord, intended from the beginning as an advanced successor to PA-RISC. Intel cancelled their own 64-bit RISC project (IAX) in 1994 to join HP's project. By that time, the major bones of what became IPF were already in place (obviously excluding x86 compatibility.)

How is it off? EPIC may have been HP's development, but the actual products were Developed by Intel (with HP) and to clear out competition HP killed two of their own CPU lines to buy these products from Intel. HP had high hopes for the technology they developed, but it cost them their own ability develop their own CPU's and locked Intel into a multi-decade support and development cycle that lasted long after Itanium "died".

Intel may have joined up with HP to work on EPIC. But HP is the one that was working with Intel, you know the company that released the only EPIC CPU, for the hardware at the cost of their own CPU design and production capability.

This seems to be a semantics game.

 

[Headfoot]

Surprised it took that long. The conclusion that you must build your software for Scale Out instead of Scale Up with bigger and faster iron has been obvious for many years, and the trend started as early as the 80's. There's really no excuse in 2019.

 

[scannall]

Intel's main reason for developing Itanium was to get away from all those pesky cross-licenensing deals they had to eat to become IBM's supplier for the IBM PC. Microsoft was rather reluctant about the whole thing. And when AMD released the AMD-64 extensions to x86, Microsoft jumped on board with that. But, AMD had to cross-license them to Intel. There were some interesting things about Itanium, but as is often the case with a first iteration it didn't live up to the hype. Plus with Microsoft pushing extending x86 to 64 bit, Intel threw the baby over the cliff instead of continuing to work on it.

 

[Tuna-Fish]

And anyway at the moment RISC-V cores are just toys. It will take years before we get any high perf RISC-V CPU... that is unless it collapses due to ISA fragmentation.

Having looked at the ISA, I don't think it's suited for high performance implementations, at least not without major extension.

For an example, to make a simple base + offset*width load that either A64 or x86 would do in a single instruction, you need 4 instructions (you do get the displacement for free, though). The designers say that this is not a problem because they can introduce instruction fusion that merges those 4 into one instruction. Except that's 16 bytes of code you need for that single very common instruction, clogging up your caches and filling up your fetch bandwidth.

I can see the design allure of having just one addressing mode, and a dead simple one at that. It certainly helps reduce register read ports, and makes simple implementations easier. But it's a huge millstone around their neck for any real performance.

 

[BigDaveX]

Itanium still had a lot of RAS features, not sure if all of those have made it into the top-end Xeons yet?

I think most of them made it across into the Xeon line with Nehalem-EX. Not sure if the Xeon's now at 100% parity with Itanium in that regard, but I'd be surprised if it weren't at least close, given that Intel have clearly been planning to dump Itanium for close on to a decade now.

IPF could still trade blows with Core2 on technical compute workloads, due to a combination of 4 LSUs, an extremely aggressive cache/memory subsystem, and a pair of very large FMA units.

Note that during that 2002-2006 period (actually a little longer) IPF was also beating SPEC numbers for Opteron, especially but not exclusively on the FP side. Do you consider K8 to be absolute garbage?

Where did I imply anything of the sort? The Xeons of that era were garbage precisely because they delivered as little as half the performance of Opteron while using twice the power to achieve that score.

Besides, just because Itanium 2 could post impressive SPEC numbers, doesn't mean it could duplicate that in general workloads. Intel's previous two attempts at a VLIW-type architecture - the iAPX 432 and i860 - both failed precisely because they delivered poor real-world performance unless they were in the hands of very talented coders.

 

[SarahKerrigan]

I think most of them made it across into the Xeon line with Nehalem-EX. Not sure if the Xeon's now at 100% parity with Itanium in that regard, but I'd be surprised if it weren't at least close, given that Intel have clearly been planning to dump Itanium for close on to a decade now.


Where did I imply anything of the sort? The Xeons of that era were garbage precisely because they delivered as little as half the performance of Opteron while using twice the power to achieve that score.

Besides, just because Itanium 2 could post impressive SPEC numbers, doesn't mean it could duplicate that in general workloads. Intel's previous two attempts at a VLIW-type architecture - the iAPX 432 and i860 - both failed precisely because they delivered poor real-world performance unless they were in the hands of very talented coders.

Fair enough. I know that one all too well, honestly - the recurring theme in my years of working with IPF is that while it could usually perform well, it was exceptionally brittle, and if you wanted a given code stream to run well, you had to be prepared to spend some time playing with it. It was rarely compile-and-forget.

(As an aside, iAPX 432 was actually a CISC design similar in some ways to Burroughs mainframes, not a VLIW or anything remotely VLIW-like. It was slow because it was big and complex, not because it was hard to program for. i860, as you correctly mention, was a horrendously finicky creature.)

 

[NostaSeronx]

Lolnope. Itanium was dead long before RISC-V was created. This announcement came on a predefined schedule, set by the contracts Intel signed long ago about providing chips to long tail customers.

There is no reason to improve(or revive) Itanium when RISC-V allows Itanium-esque instruction encoding/decoding.

Completely closed and proprietary is worse than partially open and proprietary. Any day.

https://github.com/srokicki/HybridDBT
https://team.inria.fr/pacap/simty/

Pretty much all post-Itanic and post-x86 pathways have been explored in RISC-V.

 

[Nothingness]

There is no reason to improve(or revive) Itanium when RISC-V allows Itanium-esque instruction encoding/decoding.

Completely closed and proprietary is worse than partially open and proprietary. Any day.

https://github.com/srokicki/HybridDBT
https://team.inria.fr/pacap/simty/

Pretty much all post-Itanic and post-x86 pathways have been explored in RISC-V.

Do you understand the difference between micro architecture and ISA? Both projects you link to are not RISC-V ISA specific.

Interesting links nonetheless, thanks

 

[NostaSeronx]

Do you understand the difference between micro architecture and ISA? Both projects you link to are not RISC-V ISA specific.

Interesting links nonetheless, thanks

ISA is the instruction set architecture.
micro-architecture is the processor architecture.

-> Itanium relationship;
www.cgo.org/cgo2010/epic8/slides/ditzel.pdf
and
arco.e.ac.upc.edu/wiki/images/8/8d/Ino_icalu_vld_main.pdf

^-- sometime after each; OoO-EPIC w/ DBT microarchitecture and Itanium/X86-64 ISA.

This however was scrapped around Kittsons swap to 32nm. Then, later same year HPE joins RISC-V.

 

[SarahKerrigan]

ISA is the instruction set architecture.
micro-architecture is the processor architecture.

-> Itanium relationship;
www.cgo.org/cgo2010/epic8/slides/ditzel.pdf
and
arco.e.ac.upc.edu/wiki/images/8/8d/Ino_icalu_vld_main.pdf

^-- sometime after each; OoO-EPIC w/ DBT microarchitecture and Itanium/X86-64 ISA.

This however was scrapped around Kittsons swap to 32nm. Then, later same year HPE joins RISC-V.

An obscure Intel Research presentation a decade ago that talks primarily about Crusoe/Efficeon means nothing about IPF.

IPF is dead. HPE has made it very clear to its customer base that the migration path is Xeon. The HP-UX customer base is being nudged to Linux/Xeon, including some kind of future migration path involving HP-UX containers under Linux. IPF sales had been in free-fall for years, so while frustrating to users, none of this is hugely surprising - the declining RISC/UNIX market simply no longer justified significant investment into IPF, especially given the last competitive Itanium CPU was Montecito, over a decade ago. Additionally, "later same year HPE joins RISC-V"? Kittson was canned in January 2013. The RISC-V foundation didn't even exist until 2015, and nor did HPE.

This is just the usual pack of Seronx lies and nonsense - vague hints strung together with irrelevancies in such a way as to look credible to the extremely gullible.

 

[chrisjames61]

ISA is the instruction set architecture.
micro-architecture is the processor architecture.

-> Itanium relationship;
www.cgo.org/cgo2010/epic8/slides/ditzel.pdf
and
arco.e.ac.upc.edu/wiki/images/8/8d/Ino_icalu_vld_main.pdf

^-- sometime after each; OoO-EPIC w/ DBT microarchitecture and Itanium/X86-64 ISA.

This however was scrapped around Kittsons swap to 32nm. Then, later same year HPE joins RISC-V.

Man, you sure know how to obfuscate.

 

[DrMrLordX]

This is just the usual pack of Seronx lies and nonsense - vague hints strung together with irrelevancies in such a way as to look credible to the extremely gullible.

And that's why we love him.