5 ms·

(Started watching at 24:30, thanks y'all). Everything he's saying misses the mark. If the only issue was hiding the memory latency of a load when you know the

(Started watching at 24:30, thanks y'all). Everything he's saying misses the mark. If the only issue was hiding the memory latency of a load when you know the address, you could solve this with existing techniques like simultaneous multithreading (a la HyperThreading), prefetch hints, etc. The need for speculation arises when you do not know ahead of time which address to access, which branch to take, etc. For example, you're accessing an element in an array and need to multiply the index by the element size. You don't know which address to load until the multiply completes, so you speculate. I don't see how the Mill's deferred load semantics help you any more than a prefetch or dummy load would. Actually, unless I'm missing something you couldn't even use the deferred load because, again, you don't have the address.

snuxoll 8y ago
> The need for speculation arises when you do not know ahead of time which address to access, which branch to take, etc. For example, you're accessing an element in an array and need to multiply the index by the element size. You don't know which address to load until the multiply completes, so you speculate. I don't see how the Mill's deferred load semantics help you any more than a prefetch or dummy load would. Actually, unless I'm missing something you couldn't even use the deferred load because, again, you don't have the address. You kind of hit three different issues here, there's three completely different scenarios I can think of off the top of my head to cover and the Mill design ties with out-of-order designs in the worst case and beats them in the other two. 1. Random I/O on array elements - nobody wins here because branch prediction and speculative loads will consistently fail, you hope your data is in cache and everybody stalls if not. 2. Sequential I/O on array elements - Mill can perform equally to an out-of-order design in most cases and beat it in others, you don't rely on the CPU seeing far enough ahead to reorder loads and have much better facilities for parallelizing common operations (their strstr example using their smear instruction, NaR values and pervasive vectors is truly mindblowing). 3. Switche statements with jump tables, the Mill's wide-issue design handles many of these cases without needing jump tables to begin with, especially when paired with speculative operations on potential NaR's. When you need to call code at another address you are again at the hands of the branch predictor and instruction prefetch, which the Mill does do and has some novel designs for that provides a low mispredict penalty and purportedly better prediction results. Ultimately though, if you keep hitting mispredicts you're in the same worst-case as you have on out-of-order designs. The Mill can't beat out-of-order designs where your code just thrashes cache, causes mispredicts all the time, etc, but it can match them without eating gobs of power.
- twtw 8y ago
  You talk about the mill as if it exists. There is no hardware, there are no benchmarks. Bloviating about the excellent performance of the mill is not valuable - showing SPEC CPU results is. VLIW performance was great too, until it wasn't. You can statically schedule everything in theory and the performance will be great, but experience suggests that giving hardware the capability to react dynamically cannot be replaced by static scheduling, except in code with limited branching and a known execution pattern. This is why VLIW works nicely for DSP, and fairly poorly for general purpose computing. The mill has been in development for 15 years, and almost done for 5. Forgive me for not holding my breath.
  - wtallis 8y ago
    > Forgive me for not holding my breath. You're the one who chose to click on the link to enter this discussion. You know that the Mill isn't in silicon yet and you're personally only interested in things that are, so why are you here? You're just trolling while other people are trying to have a productive academic discussion.
    - twtw 8y ago
      This "productive academic discussion" of the myriad benefits of the mill architecture has been repeated over and over again for at least 5 years, with very few new developments. There is great value to thinking about new and non traditional architectures, but discussion around this particular venture is pretty tired. I don't know that much more discussion is valuable at this point without some evidence.
      - deleted 8y ago
        [deleted]
      - wtallis 8y ago
        > has been repeated over and over again for at least 5 years, with very few new developments. The same is true of discussions of Intel's architectures; they've only released one new microarchitecture in the past 5 years. Hardware development is slow, even for the people who are already shipping silicon.

snuxoll 8y ago

> The need for speculation arises when you do not know ahead of time which address to access, which branch to take, etc. For example, you're accessing an element in an array and need to multiply the index by the element size. You don't know which address to load until the multiply completes, so you speculate. I don't see how the Mill's deferred load semantics help you any more than a prefetch or dummy load would. Actually, unless I'm missing something you couldn't even use the deferred load because, again, you don't have the address. You kind of hit three different issues here, there's three completely different scenarios I can think of off the top of my head to cover and the Mill design ties with out-of-order designs in the worst case and beats them in the other two. 1. Random I/O on array elements - nobody wins here because branch prediction and speculative loads will consistently fail, you hope your data is in cache and everybody stalls if not. 2. Sequential I/O on array elements - Mill can perform equally to an out-of-order design in most cases and beat it in others, you don't rely on the CPU seeing far enough ahead to reorder loads and have much better facilities for parallelizing common operations (their strstr example using their smear instruction, NaR values and pervasive vectors is truly mindblowing). 3. Switche statements with jump tables, the Mill's wide-issue design handles many of these cases without needing jump tables to begin with, especially when paired with speculative operations on potential NaR's. When you need to call code at another address you are again at the hands of the branch predictor and instruction prefetch, which the Mill does do and has some novel designs for that provides a low mispredict penalty and purportedly better prediction results. Ultimately though, if you keep hitting mispredicts you're in the same worst-case as you have on out-of-order designs. The Mill can't beat out-of-order designs where your code just thrashes cache, causes mispredicts all the time, etc, but it can match them without eating gobs of power.

twtw 8y ago
You talk about the mill as if it exists. There is no hardware, there are no benchmarks. Bloviating about the excellent performance of the mill is not valuable - showing SPEC CPU results is. VLIW performance was great too, until it wasn't. You can statically schedule everything in theory and the performance will be great, but experience suggests that giving hardware the capability to react dynamically cannot be replaced by static scheduling, except in code with limited branching and a known execution pattern. This is why VLIW works nicely for DSP, and fairly poorly for general purpose computing. The mill has been in development for 15 years, and almost done for 5. Forgive me for not holding my breath.
- wtallis 8y ago
  > Forgive me for not holding my breath. You're the one who chose to click on the link to enter this discussion. You know that the Mill isn't in silicon yet and you're personally only interested in things that are, so why are you here? You're just trolling while other people are trying to have a productive academic discussion.
  - twtw 8y ago
    This "productive academic discussion" of the myriad benefits of the mill architecture has been repeated over and over again for at least 5 years, with very few new developments. There is great value to thinking about new and non traditional architectures, but discussion around this particular venture is pretty tired. I don't know that much more discussion is valuable at this point without some evidence.
    - deleted 8y ago
      [deleted]
    - wtallis 8y ago
      > has been repeated over and over again for at least 5 years, with very few new developments. The same is true of discussions of Intel's architectures; they've only released one new microarchitecture in the past 5 years. Hardware development is slow, even for the people who are already shipping silicon.