Itanium had massive caches, and the main challenge with software scheduling wasn’t really memory latency. IA64’s instruction bundles weren’t particularly “large” (and it wasn’t strictly VLIW), and many of the classic VLIW compiler issues had largely been addressed by the ’80s. A lot of the FUD around its compilers didn’t fully reflect reality.

In practice, Itanium 2 was more than competitive with the high-end OoO RISC chips of the time (AXP, PA, MIPS...), and it outperformed many in-order designs like SPARC. From a pure performance standpoint, the architecture had clear merit. There was also nothing inherent in IA64 that precluded out-of-order implementations, later designs were even expected to push further in that direction.

Where Itanium struggled was elsewhere: heavy reliance on predication, very large multi-ported register files, and the resulting power inefficiency. And like many high-end architectures of that era, it ran into the realities of design cost and economies of scale.

What Itanium ultimately showed is that there’s no “free lunch” in performance. It ended up using similar or larger transistor budgets to hit its targets. Not unlike today, where “simpler” RISC cores often grow as large as (or larger than) complex x86 designs to compete. The original goal of simplifying superscalar scheduling just shifted the complexity elsewhere, largely negating the intended savings.