To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3
Yeah EPIC pushed too much effort onto compilers and removed the context awareness of out of order reordering etc and the result was just a lame duck.
Itanium is yet another example of how difficult it is to fight software ecosystem momentum.
It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded, you stall while an OoO processor keeps going and a speculative OoO processor even keeps guessing. With multiple workloads on the same hardware (virtualization, multitasking, multitenancy) this becomes an intractable problem even in the presence of the magic compiler which can solve for software based unpredictability (branch likelihood and pointer chasing), because every context switch clobbers an unknown set of cache lines and blows the entire thing up.
VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload.
Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.