4 ms·

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 Arch

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.

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.