Itanium was really good at raw performance as long as you could write hand tuned math kernels or kept working with the compiler team to optimize code for your kernel. Took me a while, but I got 97% efficiency with single core DGEMM.
So, a lot like coding for the GPU. Makes sense, given that the low-level architecture is so similar... And it might explain why VLIW itself is not so widely used anymore. AIUI, even the Mill proposed architecture (which boils down to VLIW + lots of tricks to cheaply improve performance on typical workloads) has a hardware-dependent, low-level "compilation" step that's quite reminiscent of what a GPU driver has to do.
I’m also curious how this could have gone a generation later: Itanium performance was critically dependent on compilers in an era where they were expensive and every vendor made their own, and the open source movement was just taking off. It seems like things could have gone much better if that’d been, say, LLVM backend & tools and higher level libraries where someone could get updates without licensing costs and wouldn’t be in the common 90s situation of needing to choose between the faster compiler and the more correct one.
Were a lot of people trying? It was a pretty difficult platform to get hold of and tinker with.
It's kind of like trying to use a GPU for general purpose computation. Itanium should have been a coprocessor.
In my experience, it's pretty widely accepted that VLIW (and EPIC) can achieve high performance and efficiency on highly regular tasks such as GEMM and FFT. That's why VLIW has been and continues to be popular for DSPs. The struggle for VLIW is general purpose code that doesn't necessarily have that same kind of regularity.