5 ms·

Saying a whole industry maybe did stuff wrong and they should try again is daft. Perhaps do some reading and save yourself going down the same path? VLIW blew

Saying a whole industry maybe did stuff wrong and they should try again is daft. Perhaps do some reading and save yourself going down the same path? VLIW blew up for obvious[0] reasons - memory access latency is a dynamic thing and can't be anticipated statically very well. Therefore an in-order VLIW chip with its basket of instructions (one of which being a mem access) will stall, the whole basket freezes, the subsequent baskets are held up in the queue, etc. That's why OOO processors won, a memory miss can to a degree be worked around by executing instructions ahead in the queue, if they're not dependent on the stalled instruction. [0] Blindingly obvious to me when it was pointed out, but it did need pointing out I have to admit.

ghusbands 6y ago
The folks working on the Mill seem to disagree. They have a VLIW-style architecture (up to 33 sub-instructions in an up-to-512-bit instruction) that they claim does not have the same drawbacks. That at least means that someone is still chasing the VLIW general purpose CPU dream.
- throwaway_pdp09 6y ago
  I'm aware of the mill and that it's VLIW-ish. You're right, I will do some (re)-reading on it to remember how it works around that (although in a video ivan goddard does say if you hit main mem randomly, no architecture can save you, mill included). DSPs, and of course GPUs, do exist and again you're right, for special purpose but important niches of course, but I was referring to general purpose CPUs but didn't make that clear. Thanks.
- drivebycomment 6y ago
  Mill has nothing to show for it. Mill has no answer for the unpredictable cache misses. Their belt idea is cute and interesting but inconsequential and irrelevant. The main challenge of the modern microprocessors is not in how many ALUs you run in parallel nor how you model and implement your register file, but how to keep the ALUs fed with data from the memory hierarchy. VLIW doesn't help you with that at all, which is why it is largely irrelevant and a tiny niche. For applications like GPU, you address the feeding problem with multiple threads through SMT/SIMT and multiple cores, and SIMD. For applications where a single thread performance is important, you use OOO and/or speculative execution to maximize the feeding of the data. If you only care about running a particular loop and you only need to meet a fixed cycle budget like DSP application, VLIW may make sense when you want to save some engineering time and you have relatively low volume. Once volume is high enough, you will likely choose an in-order superscalar instead, for better performance or even simpler implementation, ease of programming, better backward compatibility and higher instruction density. VLIW has become more of a niche even in DSP. E.g. see https://www.eetimes.com/a-case-for-superscalar-dsps/ https://www.eetimes.com/a-case-for-superscalar-dsps/ which is now almost 20 years old article. The basic idea behind VLIW of moving as much work as you can to the compiler is not wrong, but VLIW turned out to be a bad way to divide work between the pipeline and the compiler.
  - zozbot234 6y ago
    > For applications where a single thread performance is important, you use OOO and/or speculative execution to maximize the feeding of the data. OOO and speculative execution are very energy-intensive per unit of compute, and hard to implement securely. Even if a VLIW-ish cpu like the Mill is still ultimately bottlenecked by memory bandwidth, avoiding pretty much every known drawback of OOO is a huge deal.
    - drivebycomment 6y ago
      For the power-efficiency, in-order superscalars proved to be efficient enough - see various in-order superscalar ARMs. Even for OOO, various ARMs and Apple showed that they can get quite power efficient. Also, more importantly, VLIW is not a power efficient approach. It fundamentally wastes instruction density. It wastes the die space - superscalar + SMT are inherently more efficient when you have more than 1 thread, and VLIW is suboptimal for SMT. It also turns out in-order superscalars can match VLIW in ALU power efficiency by powering off unused ALUs just like VLIW can, and for applications where the power efficiency is more important, the control logic can be simplified enough (at the price of performance obviously) to add negligible power overhead. As for the security aspect of the speculative execution, OOO outperforms VLIW dramatically for a single thread performance even without any speculative execution. Moreover, since the discovery of Spectre, there's been plenty of research into how to do speculative execution without leaking: https://ieeexplore.ieee.org/abstract/document/8806916 https://ieeexplore.ieee.org/abstract/document/8806916 https://ieeexplore.ieee.org/abstract/document/8574559 https://ieeexplore.ieee.org/abstract/document/8574559 https://ieeexplore.ieee.org/abstract/document/9138957 https://ieeexplore.ieee.org/abstract/document/9138957 https://dl.acm.org/doi/abs/10.1145/3316781.3317914 https://dl.acm.org/doi/abs/10.1145/3316781.3317914 It's not yet clear what approach will actually win out and will be adopted, but it's clear there are multiple viable solutions such that this is a solvable problem. The whackamole of fixing / addressing individual spectre-like vulnerability likely will continue for a while - after all, processor folks didn't have that much time given the development cycle for new pipeline/architecture is measured in years - but it's unlikely that side-channel issue will make speculative execution not viable. Edit: s/SIMT/SMT/

ghusbands 6y ago

The folks working on the Mill seem to disagree. They have a VLIW-style architecture (up to 33 sub-instructions in an up-to-512-bit instruction) that they claim does not have the same drawbacks. That at least means that someone is still chasing the VLIW general purpose CPU dream.

throwaway_pdp09 6y ago
I'm aware of the mill and that it's VLIW-ish. You're right, I will do some (re)-reading on it to remember how it works around that (although in a video ivan goddard does say if you hit main mem randomly, no architecture can save you, mill included). DSPs, and of course GPUs, do exist and again you're right, for special purpose but important niches of course, but I was referring to general purpose CPUs but didn't make that clear. Thanks.
drivebycomment 6y ago
Mill has nothing to show for it. Mill has no answer for the unpredictable cache misses. Their belt idea is cute and interesting but inconsequential and irrelevant. The main challenge of the modern microprocessors is not in how many ALUs you run in parallel nor how you model and implement your register file, but how to keep the ALUs fed with data from the memory hierarchy. VLIW doesn't help you with that at all, which is why it is largely irrelevant and a tiny niche. For applications like GPU, you address the feeding problem with multiple threads through SMT/SIMT and multiple cores, and SIMD. For applications where a single thread performance is important, you use OOO and/or speculative execution to maximize the feeding of the data. If you only care about running a particular loop and you only need to meet a fixed cycle budget like DSP application, VLIW may make sense when you want to save some engineering time and you have relatively low volume. Once volume is high enough, you will likely choose an in-order superscalar instead, for better performance or even simpler implementation, ease of programming, better backward compatibility and higher instruction density. VLIW has become more of a niche even in DSP. E.g. see https://www.eetimes.com/a-case-for-superscalar-dsps/ https://www.eetimes.com/a-case-for-superscalar-dsps/ which is now almost 20 years old article. The basic idea behind VLIW of moving as much work as you can to the compiler is not wrong, but VLIW turned out to be a bad way to divide work between the pipeline and the compiler.
- zozbot234 6y ago
  > For applications where a single thread performance is important, you use OOO and/or speculative execution to maximize the feeding of the data. OOO and speculative execution are very energy-intensive per unit of compute, and hard to implement securely. Even if a VLIW-ish cpu like the Mill is still ultimately bottlenecked by memory bandwidth, avoiding pretty much every known drawback of OOO is a huge deal.
  - drivebycomment 6y ago
    For the power-efficiency, in-order superscalars proved to be efficient enough - see various in-order superscalar ARMs. Even for OOO, various ARMs and Apple showed that they can get quite power efficient. Also, more importantly, VLIW is not a power efficient approach. It fundamentally wastes instruction density. It wastes the die space - superscalar + SMT are inherently more efficient when you have more than 1 thread, and VLIW is suboptimal for SMT. It also turns out in-order superscalars can match VLIW in ALU power efficiency by powering off unused ALUs just like VLIW can, and for applications where the power efficiency is more important, the control logic can be simplified enough (at the price of performance obviously) to add negligible power overhead. As for the security aspect of the speculative execution, OOO outperforms VLIW dramatically for a single thread performance even without any speculative execution. Moreover, since the discovery of Spectre, there's been plenty of research into how to do speculative execution without leaking: https://ieeexplore.ieee.org/abstract/document/8806916 https://ieeexplore.ieee.org/abstract/document/8806916 https://ieeexplore.ieee.org/abstract/document/8574559 https://ieeexplore.ieee.org/abstract/document/8574559 https://ieeexplore.ieee.org/abstract/document/9138957 https://ieeexplore.ieee.org/abstract/document/9138957 https://dl.acm.org/doi/abs/10.1145/3316781.3317914 https://dl.acm.org/doi/abs/10.1145/3316781.3317914 It's not yet clear what approach will actually win out and will be adopted, but it's clear there are multiple viable solutions such that this is a solvable problem. The whackamole of fixing / addressing individual spectre-like vulnerability likely will continue for a while - after all, processor folks didn't have that much time given the development cycle for new pipeline/architecture is measured in years - but it's unlikely that side-channel issue will make speculative execution not viable. Edit: s/SIMT/SMT/