4 ms·

The most prominent example of VLIW processors was the Itanic, er, Itanium. It, er, didn't work out well. Hence Itanic. Their premise was that the compiler co

The most prominent example of VLIW processors was the Itanic, er, Itanium. It, er, didn't work out well. Hence Itanic. Their premise was that the compiler could figure out dependencies sufficiently statically so that they could put multiple sequential and some divergent execution paths in the same instruction. It turned out the compilers couldn't actually do this, so processors figure out dependencies and parallelizable instructions dynamically from a sequential instruction stream. Which is a lot of work, a lot of chip resources and a lot of energy. And only works up to a point, after which you hit diminishing returns. Which is where we appear to be these days.

kimixa 3y ago
VLIW is also still heavily used in DSPs and similar. And arguably the dual issue instructions in both AMD's and Nvidia's latest GPUs is a step back towards that. It feels like a lot of these things are cyclical - the core ideas aren't new and phase in and out of favor as other parts of architecture design changes around and increases or decreases benefits accordingly.
- gpderetta 3y ago
  It is not so much that it is cyclical than VLIW being good for numerical/DSP stuff with more predictable memory access and terrible for general computation. Itanium was ok at floating point code, but terrible at typical pointer chasing loads.
- hajile 3y ago
  This is less cyclical and more common sense changes. AMD used to have 5-wide VLIW. Theoretical performance was massive, but NOTHING could take advantage of 5-wide parallelism consistently. When they switched to VLIW-4, essentially zero performance per CU was lost. GCN went the complete opposite direction and got rid of all the VLIW in exchange for tons of flexibility. It turns out that (as we've known for a very long time) in-order parallelism has diminishing returns. If you look at in-order CPUs for example, two generic execution ports can be used something like 80% of the time. Moving to 3 in-order drops the usage of the third to something like 15-30% and the fourth is single digits of usage. Adding a second port should guarantee lots of use, but only if the second unit is kept flexible. RDNA3 can only use the second port for a handful of operations which means that it can't be used anywhere near that 80% metric for most applications. Future versions of RDNA and CDNA with more flexible second ports should start to be able to leverage those extra compute units (if they decide it's worth the transistors).
Symmetry 3y ago
I'd argue that the Hexagon DSPs shipped with all Qualcomm's phone SoC which a large number of us have in our pockets right now are probably more prominent example. Itanium's problem wasn't so much divergent control flow as not being able to handle unpredictable latencies on load instructions without halting all execution entirely. There were some features that were, in theory, supposed to deal with this but using them was where the magic compiler problem came in. For DSPs you can usually predict memory latency so this isn't an issue and VLIW works great there even with some amount of branching.
ip26 3y ago
It worked fine for graphics chips for a long time. Graphics workloads have embarrassing levels of static ILP.

kimixa 3y ago

VLIW is also still heavily used in DSPs and similar. And arguably the dual issue instructions in both AMD's and Nvidia's latest GPUs is a step back towards that. It feels like a lot of these things are cyclical - the core ideas aren't new and phase in and out of favor as other parts of architecture design changes around and increases or decreases benefits accordingly.

gpderetta 3y ago
It is not so much that it is cyclical than VLIW being good for numerical/DSP stuff with more predictable memory access and terrible for general computation. Itanium was ok at floating point code, but terrible at typical pointer chasing loads.
hajile 3y ago
This is less cyclical and more common sense changes. AMD used to have 5-wide VLIW. Theoretical performance was massive, but NOTHING could take advantage of 5-wide parallelism consistently. When they switched to VLIW-4, essentially zero performance per CU was lost. GCN went the complete opposite direction and got rid of all the VLIW in exchange for tons of flexibility. It turns out that (as we've known for a very long time) in-order parallelism has diminishing returns. If you look at in-order CPUs for example, two generic execution ports can be used something like 80% of the time. Moving to 3 in-order drops the usage of the third to something like 15-30% and the fourth is single digits of usage. Adding a second port should guarantee lots of use, but only if the second unit is kept flexible. RDNA3 can only use the second port for a handful of operations which means that it can't be used anywhere near that 80% metric for most applications. Future versions of RDNA and CDNA with more flexible second ports should start to be able to leverage those extra compute units (if they decide it's worth the transistors).

Symmetry 3y ago

I'd argue that the Hexagon DSPs shipped with all Qualcomm's phone SoC which a large number of us have in our pockets right now are probably more prominent example. Itanium's problem wasn't so much divergent control flow as not being able to handle unpredictable latencies on load instructions without halting all execution entirely. There were some features that were, in theory, supposed to deal with this but using them was where the magic compiler problem came in. For DSPs you can usually predict memory latency so this isn't an issue and VLIW works great there even with some amount of branching.

ip26 3y ago

It worked fine for graphics chips for a long time. Graphics workloads have embarrassing levels of static ILP.