5 ms·

(Mill team) Any questions, ask away, happy to explain or dodge as appropriate ;)

restalis 11y ago
I haven't seen the video yet (2h is not that easy), but I'm curious - currently most of the time fast CPUs spend is waiting for cache misses. Does Mill CPU Architecture deal somehow with this besides the claimed "10x single-thread power/performance gain over conventional out-of-order superscalar architectures"¹? ¹ https://en.wikipedia.org/wiki/Mill_CPU_Architecture https://en.wikipedia.org/wiki/Mill_CPU_Architecture
- willvarfar 11y ago
  If you go zigzagging all over main DRAM or disk unpredictably then there's no magic wand we can wave ;) We can however make generally less memory accesses overall, as we have backless memory When you do a load you specify when it will retire, and it will get the value in memory at the time it retires. What happens is that the load-store unit goes off and gets the memory as soon as possible, swallowing latency, but snoops on the cache coherency traffic. http://millcomputing.com/topic/memory/ http://millcomputing.com/topic/memory/ is a good starting talk on this aspect of the Mill.
  - benou 11y ago
    I am curious about how does it compare to streaming loads? It is a common technic to avoid cache misses when you have a large number of registers, you can issue loads in advance, by-passing the cache, and the CPU will manage the data dependency in HW. The idea is that hopefully when the you will use the register, its data will already be available. Otherwise you stall as usual.
    - willvarfar 11y ago
      There are many facets to this. From a great height they are roughly simular, but in the details they differ. For example, the Mill is a belt machine and each stack frame has its own belt and the hardware takes care of spilling in-flights across calls to any depth. Also, the Mill loads are orthogonal to cache management and we offer immunity to aliasing and false sharing.
Robi395 11y ago
Hi Will, A recurring question by the audience in the talks is that you will not get many benefits from such a wide architecture on general purpose code because of there is not enough "available parallelism". Do you have any concrete code examples where the Mill will find stuff to do where a OOO will not?
- willvarfar 11y ago
  There are lots of small ways we can get more units in use more of the time. ILP is a bit of a misnomer on the Mill as each Mill instruction contains many operations and these execute in 'phases' over the subsequent cycles. In the extreme(ly common) case you have a single-instruction tight loop but the second phase of the first iteration is running as the first phase of the second iteration runs. Mind-bending. We have more success at speculation than a mainstream machine as we have cheap null and `None` propagation; see http://millcomputing.com/topic/metadata/ http://millcomputing.com/topic/metadata/ And as the Mill is a belt machine, and as the hardware manages the call stack, the units can be in use by the caller even when the PC is in the callee. If you schedule, say, a `multiply` that takes 4 cycles and then next cycle call into a function (which usually takes just a cycle) then the machine can go run the function, however long it takes. When the function returns that `multiply` has long since completed but the spiller is going to use result replay to drop the results on the belt at the right time. A lot of time is spent in loops, though, and the Mill does really well at those! On the Mill, all levels of loop can be pipelined because each level of loop is given its own call frame, allowing the result replay to work. See http://millcomputing.com/topic/pipelining/ http://millcomputing.com/topic/pipelining/ Sorry for linking to just so many of the talks! ;)
  - Robi395 11y ago
    Thanks, I'll take a look at those links. In the meantime, I have another question. How much do the Mill team plan to share with the general public before any product release, can we expect a emulator, it would be great to toy with.
    - willvarfar 11y ago
saucetenuto 11y ago
Where should I go to understand your work if I hate watching videos but like reading? Is the wiki the best resource?
- willvarfar 11y ago
  We are pretty light on whitepapers and stuff, but we have this: http://millcomputing.com/topic/introduction-to-the-mill-cpu-programming-model-2/ http://millcomputing.com/topic/introduction-to-the-mill-cpu-...
- travisb 11y ago
  You might try http://liberomnia.org/wiki/Computer/The_Mill.en.html http://liberomnia.org/wiki/Computer/The_Mill.en.html for an overview, though the animations in the videos do make it significantly easier to achieve an intuitive understanding in many cases.
- infogulch 11y ago
  Try watching the videos in 1.5x or 2x speed on youtube. This gives you the same information density as reading and you don't miss the nice animations travisb mentioned.
vanderZwan 11y ago
Perhaps it's been addressed in the talk (still listening to it), but what kinds of programming languages/paradigms are particularly well suited for the belt-model? I mean, it's nice to be assured the Mill is a general purpose CPU that handles most existing code really well, but what kind of code would it handle really well, if you know what I mean? And what kind of programming language would be well suited to making good use of its strengths?
- tolmar 11y ago
  They have better than usual performance on function calls, so feed it a poorly optimized Lisp and you'll probably get a large relative performance advantage. But I don't think that's what you're looking for. Going through the most striking parts of the architecture: - They can pipeline outer loops, even with function calls in them. I expect that will perform well on event loop patterns like you find in non-blocking IO server frameworks. - They have cheap pipelining, vector operations, and (in the high-end models) lots of functional units. All the statistical languages like R and Julia should be able to get something out of that. - If you have a lot of repeated pure loops (ie: map() calls), your compiler could optimize two loops into one to try to saturate the mill's functional units. Using their pick and smear operations, I think you can even get this to work on different-size loops (with less benefit the more their sizes differ, of course). - They have novel memory protection stuff, but that's more OS than programming language. I'm clearly not part of the Mill team though, so I could be wrong about any or all of those.
lealanko 11y ago
Do I understand correctly that the load-time code specialization described in this presentation is not inherent to the Mill hardware, but instead merely a proposed OS-level mechanism for supporting binaries that are portable across the model family? Could a Mill-targeting compiler choose to bypass this mechanism and directly output model-specific concrete code?
- wtallis 11y ago
  The specialization isn't necessarily load-time. I think they're envisioning it as most likely being an install-time process, so that distributed code is still portable but they don't have to worry quite so hard about the latency of the specializer. Ahead-of-time specialization will still need to be possible for creating things like bootloaders and OS install media. I think it's safe to say that the future will have a lot of fat binaries.

I haven't seen the video yet (2h is not that easy), but I'm curious - currently most of the time fast CPUs spend is waiting for cache misses. Does Mill CPU Architecture deal somehow with this besides the claimed "10x single-thread power/performance gain over conventional out-of-order superscalar architectures"¹? ¹ https://en.wikipedia.org/wiki/Mill_CPU_Architecture https://en.wikipedia.org/wiki/Mill_CPU_Architecture

willvarfar 11y ago
If you go zigzagging all over main DRAM or disk unpredictably then there's no magic wand we can wave ;) We can however make generally less memory accesses overall, as we have backless memory When you do a load you specify when it will retire, and it will get the value in memory at the time it retires. What happens is that the load-store unit goes off and gets the memory as soon as possible, swallowing latency, but snoops on the cache coherency traffic. http://millcomputing.com/topic/memory/ http://millcomputing.com/topic/memory/ is a good starting talk on this aspect of the Mill.
- benou 11y ago
  I am curious about how does it compare to streaming loads? It is a common technic to avoid cache misses when you have a large number of registers, you can issue loads in advance, by-passing the cache, and the CPU will manage the data dependency in HW. The idea is that hopefully when the you will use the register, its data will already be available. Otherwise you stall as usual.
  - willvarfar 11y ago
    There are many facets to this. From a great height they are roughly simular, but in the details they differ. For example, the Mill is a belt machine and each stack frame has its own belt and the hardware takes care of spilling in-flights across calls to any depth. Also, the Mill loads are orthogonal to cache management and we offer immunity to aliasing and false sharing.

Robi395 11y ago

Hi Will, A recurring question by the audience in the talks is that you will not get many benefits from such a wide architecture on general purpose code because of there is not enough "available parallelism". Do you have any concrete code examples where the Mill will find stuff to do where a OOO will not?

willvarfar 11y ago
There are lots of small ways we can get more units in use more of the time. ILP is a bit of a misnomer on the Mill as each Mill instruction contains many operations and these execute in 'phases' over the subsequent cycles. In the extreme(ly common) case you have a single-instruction tight loop but the second phase of the first iteration is running as the first phase of the second iteration runs. Mind-bending. We have more success at speculation than a mainstream machine as we have cheap null and `None` propagation; see http://millcomputing.com/topic/metadata/ http://millcomputing.com/topic/metadata/ And as the Mill is a belt machine, and as the hardware manages the call stack, the units can be in use by the caller even when the PC is in the callee. If you schedule, say, a `multiply` that takes 4 cycles and then next cycle call into a function (which usually takes just a cycle) then the machine can go run the function, however long it takes. When the function returns that `multiply` has long since completed but the spiller is going to use result replay to drop the results on the belt at the right time. A lot of time is spent in loops, though, and the Mill does really well at those! On the Mill, all levels of loop can be pipelined because each level of loop is given its own call frame, allowing the result replay to work. See http://millcomputing.com/topic/pipelining/ http://millcomputing.com/topic/pipelining/ Sorry for linking to just so many of the talks! ;)
- Robi395 11y ago
  Thanks, I'll take a look at those links. In the meantime, I have another question. How much do the Mill team plan to share with the general public before any product release, can we expect a emulator, it would be great to toy with.
  - willvarfar 11y ago

saucetenuto 11y ago

Where should I go to understand your work if I hate watching videos but like reading? Is the wiki the best resource?

willvarfar 11y ago
We are pretty light on whitepapers and stuff, but we have this: http://millcomputing.com/topic/introduction-to-the-mill-cpu-programming-model-2/ http://millcomputing.com/topic/introduction-to-the-mill-cpu-...
travisb 11y ago
You might try http://liberomnia.org/wiki/Computer/The_Mill.en.html http://liberomnia.org/wiki/Computer/The_Mill.en.html for an overview, though the animations in the videos do make it significantly easier to achieve an intuitive understanding in many cases.
infogulch 11y ago
Try watching the videos in 1.5x or 2x speed on youtube. This gives you the same information density as reading and you don't miss the nice animations travisb mentioned.

vanderZwan 11y ago

Perhaps it's been addressed in the talk (still listening to it), but what kinds of programming languages/paradigms are particularly well suited for the belt-model? I mean, it's nice to be assured the Mill is a general purpose CPU that handles most existing code really well, but what kind of code would it handle really well, if you know what I mean? And what kind of programming language would be well suited to making good use of its strengths?

tolmar 11y ago
They have better than usual performance on function calls, so feed it a poorly optimized Lisp and you'll probably get a large relative performance advantage. But I don't think that's what you're looking for. Going through the most striking parts of the architecture: - They can pipeline outer loops, even with function calls in them. I expect that will perform well on event loop patterns like you find in non-blocking IO server frameworks. - They have cheap pipelining, vector operations, and (in the high-end models) lots of functional units. All the statistical languages like R and Julia should be able to get something out of that. - If you have a lot of repeated pure loops (ie: map() calls), your compiler could optimize two loops into one to try to saturate the mill's functional units. Using their pick and smear operations, I think you can even get this to work on different-size loops (with less benefit the more their sizes differ, of course). - They have novel memory protection stuff, but that's more OS than programming language. I'm clearly not part of the Mill team though, so I could be wrong about any or all of those.

lealanko 11y ago

Do I understand correctly that the load-time code specialization described in this presentation is not inherent to the Mill hardware, but instead merely a proposed OS-level mechanism for supporting binaries that are portable across the model family? Could a Mill-targeting compiler choose to bypass this mechanism and directly output model-specific concrete code?

wtallis 11y ago
The specialization isn't necessarily load-time. I think they're envisioning it as most likely being an install-time process, so that distributed code is still portable but they don't have to worry quite so hard about the latency of the specializer. Ahead-of-time specialization will still need to be possible for creating things like bootloaders and OS install media. I think it's safe to say that the future will have a lot of fat binaries.