Hacker News Reader

Superscalar just means the processor can execute more than one instruction at a time (in parallel, not just pipelined). The main distinction between VLIW and mainstream x86 is in how the instruction execution is scheduled: x86 cores track dependencies between instructions, and most support reordering instructions to deal with stalls from things like cache misses or the next instruction being of the wrong type for any of the free execution ports. VLIW relies on the compiler to schedule instructions, so that the hardware does not need to do dependency tracking.

And the problem is that such a thing doesn't really work on mainstream CPUs, because memory access instructions take a highly variable amount of cycles depending on which cache level the data is in, which the compiler cannot know, and generating code for all possibilities leads to exponential blowup of the source code size.

It's not clear how Intel thought it could possibly work.

predication and queues can go a long way

Fundamentally it seems though that more information is available at run time? You may get partway there in the compiler, but assuming you have sufficient transistor budget, it seems more optimal to do reordering in the CPU.

The runtime doesn't know all that much, though. All it has is a single instruction flow, that it can extract fine-grained parallelism from and try to speed up further via speculation. Nothing whatsoever about other work that may be scheduled in when the processor is stalled by memory, other than via SMT. Nothing about priorities or coarse-grained dependencies among work units. So there's a lot of parallelism that's left on the table, and a lot of speculated work that might just be wasted.

> The runtime doesn't know all that much […]

If we are talking about JIT, yes, it does, for it instruments the runtime, gathers the information about hot code paths and performs the in-place optimisation. Think of the profile guide compile time optimisation having been carried over into the runtime.

Out of three VLIW architectures I have looked into, 2x (Elbrus and Itanium) rely on the predication heavily. i860 does not have instruction predicates.

Predication places the burden of creating optimal instruction bundles AND the correct hinting via the use of predicates on the compiler. If stars aligned, the code could perform blazingly fast. It turned out that aligning the stars in an optimal space time sequence was an arduous task due to the actual hints only being available at the runtime.

Which is where JIT has delivered well (and cheaper!) without requiring a radically different VLIW design.

> ...I read many engineers in many places saying that it's a bad [idea]...

I read an article several years ago from an engineer at...ooh, I think it was DEC or IBM. He said that during development of the Itanium, the Intel guys had talked to them and they advised most strongly that Intel drop the project, because they had been down that road and thought it was a dead end.

VLIW still lives today in various guises. GPUs are the most obvious.

Even the M1 could be argued to be close, it’s a very wide machine.

Recent GPUs have been RISC for some time now. Since AMD replaced their TeraScale architecture.

Can GPUs really be considered VLIW just because they might share an instruction pointer across a couple of 'micro cores'? AFAIK they went even back from SIMD to scalar a long time ago.

I suppose. They’re still very wide machines, which to me seems like the most interesting aspect of VLIW.

Of course actual VLIW still are around as DSPs.

No, I don't think so. It's one instruction on multiple data (SIMD). That's the essence of a vector op!

No, not really.

VLIW is considered: Multiple Instruction Multiple Data, in each line of assembly you can send out something like 4 (or 8) instruction each with a different target, and it will work as long as there aren't dependency issues.

GPUs are still Single Instruction Multiple Data (SIMD), for every vector operation you are doing operation: adding vectors, taking a dot production you are only executing a single op at a time.

SIMDs are really close to the RISC/CISC paradigm, and there's various extensions for other types of SIMD processing in different ISAs used today. VLIW is a much different set of assumptions, requiring the compiler to program in the same instruction level parallelism that a superscalar chip will parallelize via it's architectural features (pipelines/branch prediction/et cetera).

> GPUs are still Single Instruction Multiple Data (SIMD), for every vector operation you are doing operation: adding vectors, taking a dot production you are only executing a single op at a time.

Sort of. It's both, really. On nvidia at least, the threads in the warp are simd, but between warps it's mimd. And that's before we get into SMs.

Qualcomm basebands apparently use VLIW in baseband in an architecture they called Hexagon: https://www.llvm.org/devmtg/2017-02-04/Halide-for-Hexagon-DS...

VLIW seems quite suited to DSP / SDR applications.

Better PDF with architecture picture about where it's used: https://developer.qualcomm.com/download/hexagon/hexagon-dsp-...

More links: https://en.wikichip.org/wiki/qualcomm/microarchitectures/hex...

https://pages.cs.wisc.edu/~danav/pubs/qcom/hexagon_micro2014...

https://blog.tensorflow.org/2019/12/accelerating-tensorflow-...

AMD's latest RDNA3 is explicitly VLIW with the VLIW instructions working on SIMD units.

Ironically, they are also running head first into the compiler issues with almost nothing around taking advantage of their dual issue potential.

VLIW has nothing to do with width and everything to do with explicit ILP (instruction level parallelism).

.. and then Nvidia brought their GPUs to the clusters and ate both Intel’s and AMDs lunch with a better version of VLIW. The CUDA programming model and hardware IMO is quite successful at abstracting vectors the right way[TM], separating the problem of the grid setup from that of the kernel code (which you can still largely program in a scalar way if you’re not after the last ~30% of performance). IMO a shame that OpenCL never got good.