4 ms·

Reminds me of VLIW. As per Wikipedia, from the Itanium page: > One VLIW instruction word can contain several independent instructions, which can be executed in

Reminds me of VLIW. As per Wikipedia, from the Itanium page: > One VLIW instruction word can contain several independent instructions, which can be executed in parallel without having to evaluate them for independence. A compiler must attempt to find valid combinations of instructions that can be executed at the same time, effectively performing the instruction scheduling that conventional superscalar processors must do in hardware at runtime. If your CPU exposed the single-stream parallelism at the interface, you can do it at compile-time or even decide it with in-line assembler. I wonder if it hasn't caught due strictly to the business dynamics of the industry, or are there technical reasons this isn't really a good strategy?

thatjoeoverthr 3y ago
Im reading that TeraScale (AMD) works this way. Itanium is a major attempt to ship it in a CPU. I guess AMD64 and ARM rule the day but maybe in the future we'll see it again.
- varelse 3y ago
  [dead]
- JonChesterfield 3y ago
  Terascale was a vliw, worked well as far as I know. The current amdgpu architectures aren't - those are multiple execution port systems, reminiscent of the x64 setup. Qualcomms' Hexagon is a vliw, I think that's contemporary. Graphcore's IPU is two instructions per word.
lizknope 3y ago
Are you asking why VLIW hasn't caught on? There are DSPs that use VLIW concepts. But for general purpose computing look at Itanium and it's failure.
Joker_vD 3y ago
Well, IIRC it didn't caught on mostly because of a) compilers weren't really that good at that kind of instruction scheduling (and when they improved, Itanium has sunk already), b) conventional ISAs (that is, x86) got quite good at doing this in hardware, at runtime, and actually deliver slightly better results than static scheduling precisely because they do it at runtime, when profiling data is available. I believe Linus has a good even if tangentially related to this exact topic rant at [0]. "While the RISC people were off trying to optimize their compilers to generate loops that used all 32 registers efficiently, the x86 implementors instead made the chip run fast on varied loads and used tons of register renaming hardware (and looking at _memory_ renaming too)." [0] https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html
- fanf2 3y ago
  Static scheduling, even with profiling, can never be as good as dynamic scheduling for general-purpose workloads. VLIW/EPIC can do well for HPC-style number crunching, but that isn't everything. https://news.ycombinator.com/context?id=37900987 https://news.ycombinator.com/context?id=37900987
gpderetta 3y ago
Because static scheduling is terrible for non-DSP and non-HPC loads like the typical server or desktop application where the control and data flow is very input dependent. Until recently DSP and HPC were a tiny fraction of the market so architectures capable of dynamic scheduling dominated even those markets as they had more investment. With GPUs of course things have changed and in fact GPUs relied more on static scheduling, but even there as they expand to more varied loads, they are acquiring more dynamism.
JonChesterfield 3y ago
One can move complexity back and forth between compiler, runtime and processor implementation to some extent. VLIW works really well in some niches. It's harder to program than single instructions that execute in sequence, either by hand or by compiler, but it simplifies the scheduling for the hardware. Works better if the bundled instructions have similar latency. The key design puzzle at present seems to be that memory access takes many more cycles than arithmetic. Bundling a few cycles of arithmetic with a few hundred cycles of memory load is kind of pointless. So VLIW works well if you know memory access is going to be fast, which roughly means knowing it'll hit in L1 cache or equivalent. I think that's part of why it suits DSP style systems. Exposed pipelines are an interesting quirk of some of these systems. One instruction in a VLIW bundle writes to a register and subsequent instructions that read from that same register will see the previous value for N subsequent cycles, after which the write becomes visible. They're really confusing to program by hand but compilers can deal with that sort of scheduling.
fanf2 3y ago
See my other comment for why VLIW was technically flawed https://news.ycombinator.com/context?id=37900987 https://news.ycombinator.com/context?id=37900987

thatjoeoverthr 3y ago

Im reading that TeraScale (AMD) works this way. Itanium is a major attempt to ship it in a CPU. I guess AMD64 and ARM rule the day but maybe in the future we'll see it again.

varelse 3y ago
[dead]
JonChesterfield 3y ago
Terascale was a vliw, worked well as far as I know. The current amdgpu architectures aren't - those are multiple execution port systems, reminiscent of the x64 setup. Qualcomms' Hexagon is a vliw, I think that's contemporary. Graphcore's IPU is two instructions per word.

lizknope 3y ago

Are you asking why VLIW hasn't caught on? There are DSPs that use VLIW concepts. But for general purpose computing look at Itanium and it's failure.

Joker_vD 3y ago

Well, IIRC it didn't caught on mostly because of a) compilers weren't really that good at that kind of instruction scheduling (and when they improved, Itanium has sunk already), b) conventional ISAs (that is, x86) got quite good at doing this in hardware, at runtime, and actually deliver slightly better results than static scheduling precisely because they do it at runtime, when profiling data is available. I believe Linus has a good even if tangentially related to this exact topic rant at [0]. "While the RISC people were off trying to optimize their compilers to generate loops that used all 32 registers efficiently, the x86 implementors instead made the chip run fast on varied loads and used tons of register renaming hardware (and looking at _memory_ renaming too)." [0] https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html

fanf2 3y ago
Static scheduling, even with profiling, can never be as good as dynamic scheduling for general-purpose workloads. VLIW/EPIC can do well for HPC-style number crunching, but that isn't everything. https://news.ycombinator.com/context?id=37900987 https://news.ycombinator.com/context?id=37900987

gpderetta 3y ago

Because static scheduling is terrible for non-DSP and non-HPC loads like the typical server or desktop application where the control and data flow is very input dependent. Until recently DSP and HPC were a tiny fraction of the market so architectures capable of dynamic scheduling dominated even those markets as they had more investment. With GPUs of course things have changed and in fact GPUs relied more on static scheduling, but even there as they expand to more varied loads, they are acquiring more dynamism.

JonChesterfield 3y ago

One can move complexity back and forth between compiler, runtime and processor implementation to some extent. VLIW works really well in some niches. It's harder to program than single instructions that execute in sequence, either by hand or by compiler, but it simplifies the scheduling for the hardware. Works better if the bundled instructions have similar latency. The key design puzzle at present seems to be that memory access takes many more cycles than arithmetic. Bundling a few cycles of arithmetic with a few hundred cycles of memory load is kind of pointless. So VLIW works well if you know memory access is going to be fast, which roughly means knowing it'll hit in L1 cache or equivalent. I think that's part of why it suits DSP style systems. Exposed pipelines are an interesting quirk of some of these systems. One instruction in a VLIW bundle writes to a register and subsequent instructions that read from that same register will see the previous value for N subsequent cycles, after which the write becomes visible. They're really confusing to program by hand but compilers can deal with that sort of scheduling.

fanf2 3y ago

See my other comment for why VLIW was technically flawed https://news.ycombinator.com/context?id=37900987 https://news.ycombinator.com/context?id=37900987