3 ms·

I wasn't familiar with VLIW. Sounds cool! > Very long instruction word (VLIW) refers to instruction set architectures designed to exploit instruction level par

I wasn't familiar with VLIW. Sounds cool! > Very long instruction word (VLIW) refers to instruction set architectures designed to exploit instruction level parallelism (ILP). Whereas conventional central processing units (CPU, processor) mostly allow programs to specify instructions to execute in sequence only, a VLIW processor allows programs to explicitly specify instructions to execute in parallel. This design is intended to allow higher performance without the complexity inherent in some other designs. > The traditional means to improve performance in processors include dividing instructions into substeps so the instructions can be executed partly at the same time (termed pipelining), dispatching individual instructions to be executed independently, in different parts of the processor (superscalar architectures), and even executing instructions in an order different from the program (out-of-order execution).[1] These methods all complicate hardware (larger circuits, higher cost and energy use) because the processor must make all of the decisions internally for these methods to work. https://en.wikipedia.org/wiki/Very_long_instruction_word https://en.wikipedia.org/wiki/Very_long_instruction_word

mpweiher 3y ago
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.
yarg 3y ago
Read up on SIMD in general. (The means of processing as opposed to the language used to dispatch commands.) (And worth baring in mind is the fact that terms such as VLIW4 and VLIW5 refer to specific implementations.) https://en.wikipedia.org/wiki/Single_instruction,_multiple_data https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
- gpderetta 3y ago
  simd != vliw though.

mpweiher 3y ago

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.

yarg 3y ago

Read up on SIMD in general. (The means of processing as opposed to the language used to dispatch commands.) (And worth baring in mind is the fact that terms such as VLIW4 and VLIW5 refer to specific implementations.) https://en.wikipedia.org/wiki/Single_instruction,_multiple_data https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...

gpderetta 3y ago
simd != vliw though.