6 ms·

I worked on a large scale project that was itanium based and let me tell you, the compilers / software toolchains were an absolute dumpster fire. We were planni

I worked on a large scale project that was itanium based and let me tell you, the compilers / software toolchains were an absolute dumpster fire. We were planning on being between 500 and 2000 processors in our cluster. We used HP boxes and I want to say it was around 2002/2003 when this was going on. We were supposed to be a huge public showpiece client for both intel and HP. It… did not go very well. I remember the absolute defeated looks of the HP / Intel people when we pulled the plug and told them the discounts / free hardware still couldn’t justify the engineering efforts we had gone through for the last 18-24 months. This was right as opterons were coming out and that project jumped ship to them.

ksec 3y ago
There were plenty of people sceptical of Itanium at the time, including many within Intel as well. I guess we all gave Intel some benefits of the doubt. But the great thing is that the whole industry learned a lot from it. Intel did too. It is just sad a lot of this learning experience within Engineering never got promoted to C-Level Management at Intel.
- acdha 3y ago
  > There were plenty of people sceptical of Itanium at the time, including many within Intel as well Credit especially goes to the people who stayed on the various x86 processor teams. Itanium’s single greatest source of failure was that successive Penguin generations undercut the advantage of x86 compatibility by adding the option of not migrating at all and still getting better performance. They probably saved the company but I doubt that got much praise at the time since it required acknowledging how badly the Itanium project had failed.
Keyframe 3y ago
That's the tragedy behind it, since the whole premise on how Itanium was done was that compilers will be able to, eventually, any day now, optimize for it and then you'll see, just wait and then you'll see.. any day now!
- javitron 3y ago
  The compilers worked just fine. Itanium was not even that particularly VLIWish, as the instruction carrier wasn't that particularly wide (up to 4 instructions) All that Itanium was, at the end of the day, was an in-order PA-RISC/SPARC hybrid that exposed a lot of the superscalar innards to the programmer (compiler) VLIW scheduling even back then wasn't as much of a mystery as the usenet and register flamewars implied. It really is pretty straightforward for a compiler to behave like an in-order superscalar scheduler. And since the compiler has a much global information about the instruction stream it can do much more optimizations and static ordering than a normal in-order HW superscalar scheduler alone. Plus itanium had plenty of dynamic microarchitectural components to complement the static ordering done by the compiler and increase FU utilization. If anything, things like predication and its adverse effect in power consumption had a much worse impact on itanium than the compilers. What killed the itanium was just simple economics; its performance was fine (for the time, at least for itanium2). It's performance/price ratio, however, was not.

ksec 3y ago

There were plenty of people sceptical of Itanium at the time, including many within Intel as well. I guess we all gave Intel some benefits of the doubt. But the great thing is that the whole industry learned a lot from it. Intel did too. It is just sad a lot of this learning experience within Engineering never got promoted to C-Level Management at Intel.

acdha 3y ago
> There were plenty of people sceptical of Itanium at the time, including many within Intel as well Credit especially goes to the people who stayed on the various x86 processor teams. Itanium’s single greatest source of failure was that successive Penguin generations undercut the advantage of x86 compatibility by adding the option of not migrating at all and still getting better performance. They probably saved the company but I doubt that got much praise at the time since it required acknowledging how badly the Itanium project had failed.

Keyframe 3y ago

That's the tragedy behind it, since the whole premise on how Itanium was done was that compilers will be able to, eventually, any day now, optimize for it and then you'll see, just wait and then you'll see.. any day now!

javitron 3y ago
The compilers worked just fine. Itanium was not even that particularly VLIWish, as the instruction carrier wasn't that particularly wide (up to 4 instructions) All that Itanium was, at the end of the day, was an in-order PA-RISC/SPARC hybrid that exposed a lot of the superscalar innards to the programmer (compiler) VLIW scheduling even back then wasn't as much of a mystery as the usenet and register flamewars implied. It really is pretty straightforward for a compiler to behave like an in-order superscalar scheduler. And since the compiler has a much global information about the instruction stream it can do much more optimizations and static ordering than a normal in-order HW superscalar scheduler alone. Plus itanium had plenty of dynamic microarchitectural components to complement the static ordering done by the compiler and increase FU utilization. If anything, things like predication and its adverse effect in power consumption had a much worse impact on itanium than the compilers. What killed the itanium was just simple economics; its performance was fine (for the time, at least for itanium2). It's performance/price ratio, however, was not.