4 ms·

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 irrelev

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/
  - zozbot234 6y ago
    > It fundamentally wastes instruction density It would seem that instruction compression can be used to recover that density in many cases. Even Itanium did something like that IIRC, and of course the Mill is noticeably reliant on cheap representation of "unused" instructions. > It wastes the die space - superscalar + SIMT are inherently more efficient when you have more than 1 thread I don't believe this at all. SIMT encompasses approaches such as barrel processing, and wide-SIMD plus predication as an alternative to branching code, that while effective in some specialized cases are hardly "inherently" preferable in general.
    - drivebycomment 6y ago
      I meant to put SMT not SIMT.
throwaway_pdp09 6y ago
Looks like you know much more than me but let's talk > Mill has nothing to show for it. so far. > Mill has no answer for the unpredictable cache misses And they state so, quite explicitly (and as no architecture can ever, as I said in another comment). so you can hardly criticise them for that. > Their belt idea is cute and interesting but inconsequential and irrelevant. It's about avoiding register forwarding, so chopping out a major chunk of very high speed hardware (AIUI). > but how to keep the ALUs fed with data from the memory hierarchy No, it depends entirely on the job. If you have tight loops with lots of ILP then you win. (as for the rest, IDK).
- magicalhippo 6y ago
  > no architecture can ever But that's the whole point of OOO isn't it? Keep executing stuff down the line while previous instructions are waiting for the cache to get filled.
  - throwaway_pdp09 6y ago
    from memory (from the hen&pat book) OOO can more-or-less hide the latency of a L2 miss. A total cache miss to main mem is far too many cycles, OOO can't hide that.
    - drivebycomment 6y ago
      > A total cache miss to main mem is far too many cycles, OOO can't hide that. That view is only a very partial understanding of the bigger story, and is missing the key benefit of OOO. The key benefit of OOO and speculative execution is that they allow you to generate multiple outstanding L2/L3 misses in flight. Memory latency is hundreds of cycles, and if you can get one more memory read in flight while there's already one miss, you cut the effective stall time for memory significantly. OOO and speculative execution help not only because they allow the pipeline to run more instructions while being stalled, they help because that extra execution can create multiple outstanding cache misses, effectively reducing the stall cycles due to cache misses.
  - 6y ago
marcosdumay 6y ago
> Mill has no answer for the unpredictable cache misses. Yes, they have. They have separated fetch and use operations and a completely rethought writing cycle. Of course, I have no idea how that actually works on practice.

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/
- zozbot234 6y ago
  > It fundamentally wastes instruction density It would seem that instruction compression can be used to recover that density in many cases. Even Itanium did something like that IIRC, and of course the Mill is noticeably reliant on cheap representation of "unused" instructions. > It wastes the die space - superscalar + SIMT are inherently more efficient when you have more than 1 thread I don't believe this at all. SIMT encompasses approaches such as barrel processing, and wide-SIMD plus predication as an alternative to branching code, that while effective in some specialized cases are hardly "inherently" preferable in general.
  - drivebycomment 6y ago
    I meant to put SMT not SIMT.

throwaway_pdp09 6y ago

Looks like you know much more than me but let's talk > Mill has nothing to show for it. so far. > Mill has no answer for the unpredictable cache misses And they state so, quite explicitly (and as no architecture can ever, as I said in another comment). so you can hardly criticise them for that. > Their belt idea is cute and interesting but inconsequential and irrelevant. It's about avoiding register forwarding, so chopping out a major chunk of very high speed hardware (AIUI). > but how to keep the ALUs fed with data from the memory hierarchy No, it depends entirely on the job. If you have tight loops with lots of ILP then you win. (as for the rest, IDK).

magicalhippo 6y ago
> no architecture can ever But that's the whole point of OOO isn't it? Keep executing stuff down the line while previous instructions are waiting for the cache to get filled.
- throwaway_pdp09 6y ago
  from memory (from the hen&pat book) OOO can more-or-less hide the latency of a L2 miss. A total cache miss to main mem is far too many cycles, OOO can't hide that.
  - drivebycomment 6y ago
    > A total cache miss to main mem is far too many cycles, OOO can't hide that. That view is only a very partial understanding of the bigger story, and is missing the key benefit of OOO. The key benefit of OOO and speculative execution is that they allow you to generate multiple outstanding L2/L3 misses in flight. Memory latency is hundreds of cycles, and if you can get one more memory read in flight while there's already one miss, you cut the effective stall time for memory significantly. OOO and speculative execution help not only because they allow the pipeline to run more instructions while being stalled, they help because that extra execution can create multiple outstanding cache misses, effectively reducing the stall cycles due to cache misses.
- 6y ago

marcosdumay 6y ago

> Mill has no answer for the unpredictable cache misses. Yes, they have. They have separated fetch and use operations and a completely rethought writing cycle. Of course, I have no idea how that actually works on practice.