HP stepping away from Itanium

[Phynaz]

HP announced today new versions of its Superdome and NonStop systems that use Intel’s mainstream x86-based Xeon processors instead of Itanium

http://www.eetimes.com/document.asp?doc_id=1324819&

What do you guys think, does EPIC/VLIW have a future?

For reference:
http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing

http://en.wikipedia.org/wiki/Very_long_instruction_word

 

[monstercameron]

Even AMD left it behind, safe to say it is mostly done for. Was transmeta vliw?

 

[ShintaiDK]

Unfortunately its dead. x86 everywhere.

 

[waffleironhead]

I'm guessing a whole bunch of workers in Fort Collins are concerned about their jobs today.

 

[mrmt]

It's nice to see that after 6 long years the Xeon EX family is taking over Itanium's place on the product line up.

 

[Arachnotronic]

I'm guessing a whole bunch of workers in Fort Collins are concerned about their jobs today.

Plenty of server projects within Intel to work on. I doubt Intel is laying off those engineers, esp. given that there is some serious talent on that team.

 

[ultimatebob]

Wow... the "Itanic" processors are still around? I thought that product line got canned years ago when Microsoft and Red Hat stopped doing new server versions for it.

 

[Phynaz]

Was transmeta vliw?

Yep

 

[monstercameron]

Yep

Is the new Tegra also vliw?

 

[NTMBK]

Been obviously coming for a year and a half. http://semiaccurate.com/2013/02/11/hp-and-intel-effectively-kill-off-itanium/

 

[Idontcare]

Been obviously coming for a year and a half. http://semiaccurate.com/2013/02/11/hp-and-intel-effectively-kill-off-itanium/

Actually this means that Oracle was right all along, and the lawsuit brought on by HP was complete BS.

 

[ShintaiDK]

Oracle made their own mistake with Sparc tho

There can be only one, and thats x86. The problem is its not the ideal choice. And we will most likely never see a new uarch again as long as there is competition of any kind. Simple risk vs reward economic factor.

 

[jhu]

Oracle made their own mistake with Sparc tho

There can be only one, and thats x86. The problem is its not the ideal choice. And we will most likely never see a new uarch again as long as there is competition of any kind. Simple risk vs reward economic factor.

It's clear x86 is the practical choice. What would you consider as the ideal choice?

 

[ShintaiDK]

It's clear x86 is the practical choice. What would you consider as the ideal choice?

Of the current, IA64.

 

[kimmel]

Actually this means that Oracle was right all along, and the lawsuit brought on by HP was complete BS.

Probably at least one side benefit from this from Oracle's point of view is that they scared people away from Itanium quicker than might otherwise would have happened.

Hard to prove the counter-factual though.

 

[mrmt]

Probably at least one side benefit from this from Oracle's point of view is that they scared people away from Itanium quicker than might otherwise would have happened.

POWER, SPARC and Itanium are dying, there isn't much anyone can do about it.

 

[Arachnotronic]

Of the current, IA64.

I don't know why...maybe the IA64 ISA is great, but the implementations of that ISA have been dogs.

 

[ShintaiDK]

I don't know why...maybe the IA64 ISA is great, but the implementations of that ISA have been dogs.

Its all about R&D budget.

 

[NTMBK]

Its all about R&D budget.

Haha, no. Itanium was Intel's great white hope. They poured billions upon billions into it. They predicted tens of billions in yearly sales.

It was a bad idea.

 

[ShintaiDK]

Haha, no. Itanium was Intel's great white hope. They poured billions upon billions into it. They predicted tens of billions in yearly sales.

It was a bad idea.

The amount spend vs x86 is tiny at best.

IA64 died due to x64. The shortcut was yet again taken and we won another 30-40 years with legacy and workarounds.

Your graph is also misleading. The first IA64 CPU launched in 2001. And it was clear in 2004 that it was a lost cause due to x64. Just look at the product releases since that time. From 1 year to 3 year schedules.

 

[Atreidin]

Haha, no. Itanium was Intel's great white hope. They poured billions upon billions into it. They predicted tens of billions in yearly sales.

It was a bad idea.

It was a bad idea, badly implemented, and even the anticipation of it made development of certain better designs essentially stop. Good riddance.

 

[Nothingness]

I don't know why...maybe the IA64 ISA is great, but the implementations of that ISA have been dogs.

No, the IA64 ISA isn't great. I really wanted to like it, but it's too complex and puts too much emphasis on compiler ability to generate good code for a quite complex ISA.

 

[NTMBK]

The amount spend vs x86 is tiny at best.

It is now, yes, because it has been abandoned as a lost cause. But not when they initially developed Itanium. They poured billions into it instead of developing their own x86-64 extensions, and lost out when AMD did the obvious thing and extended the market's preferred ISA.

Itanium was just flat out awful. Ding, dong, the witch is dead.

 

[ShintaiDK]

It is now, yes, because it has been abandoned as a lost cause. But not when they initially developed Itanium. They poured billions into it instead of developing their own x86-64 extensions, and lost out when AMD did the obvious thing and extended the market's preferred ISA.

So tell me, how much R&D money was used on Itanium and how much on x86. Something like Haswell alone for example most likely cost more than the entire Itanium project.

And x64 was a terrible hotfix solution to the real problem ahead. And you should know that by now.

IA64 was the last risk you ever see before a complete CPU monopoly across all segments.

 

[ShintaiDK]

No, the IA64 ISA isn't great. I really wanted to like it, but it's too complex and puts too much emphasis on compiler ability to generate good code for a quite complex ISA.

You are not going to get 12+ issue wide cores without that. People already complain about progression with x86 now. Today we have no alternative to x86.