Parallel Alpha systems are a pain to deal with, because they lack a form of expected synchronization that every other processor has: automatic data dependency barriers. On every other platform, if you initialize or otherwise write to a value, then make a pointer point to that value, you can expect that anyone reading through that pointer gets the initialized/new value. But on Alpha, another CPU can get the new value of the pointer and then the uninitialized/old value of what it points to.
Alpha is the sole reason why the Linux kernel "smp_read_barrier_depends" barrier exists and code has to use it; on every other platform, that barrier is a no-op.
I'd guess that back when the alpha memory model was designed multiprocessors were quite rare, and designers didn't have such a clear picture of the tradeoffs that we do today (not saying today's understanding is perfect, just that it's better than what we had 30 years ago), and chose the weakest possible model they could come up with in order to not constrain future designers.
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.
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.
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.
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.
I have to admit that as a DEC alpha user starting in 1993 (using OSF/1), and also one of the main FreeBSD/alpha port authors, the itanium being phased out fills me with joy.
Around the time that the Itanium project was announced (and had presumably been being worked on behind the scenes for quite a while) was when Compaq bought DEC. HP wouldn't buy Compaq until about 5 years later. So Itanium was already well underway by the time switching to Alpha would have been a remote possibility.