3 ms·
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 t
by 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 agoThe 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.