8 ms·
The Mill CPU Architecture – The Compiler [video]
- JoachimS 11y agoHave they moved beyond vapor ware phase yet? Working silicon?
- trsohmers 11y agoNope, they don't even have FPGA prototypes yet.
- vtsrh 11y agoIt is a start-up. They just got their patents up last year, demanding working hardware seems unreasonable and they have working machines simulated in software.
- Zecc 11y agoPlus, I think they mention somewhere their whole long-time plan is to only license the architecture to third-party hardware manufacturers.
- thristian 11y agoI recall somebody asking Ivan about that in a previous talk, and he pointed out that Intel is a much larger company than ARM, so they'd rather manufacture and sell chips, and fall back on licensing the architecture if Plan A didn't work out.
- madez 11y agoWhy is being a big company something to strive for?
- TazeTSchnitzel 11y agoGreed?
- kinghajj 11y agoIvan said something in the aforementioned video to the effect of "Last year, Intel's dividend was as much as ARM Holding's entire revenue."
- kjs3 11y agoWhat are they going to do? Kickstarter up $3-4 billion for a fab? Seriously?
- vtsrh 11y agoThey haven't promised a product, so calling it vapor-ware is unwarranted. So far they have delivered as much as they have promised.
- kjs3 11y agoMore performance art at this point.
- CyberDildonics 11y agoThis company is built to produce patents, which they have succeeded at doing I believe.
- fla 11y agoThe answer at 1:26:12 [1] about the belt being in fact a 'proxy' of the bypass network is very interesting. [1] https://youtu.be/D7GDTZ45TRw?t=5172 https://youtu.be/D7GDTZ45TRw?t=5172
- signa11 11y agoyeah well during mis-predictions, interrupts etc. undoing that entire state (of name-mappings, and re-create a different one perhaps) might not be easy. moreover, since it is running kind of a cycle ahead, it seems that this whole network, seems more like a cross-bar switch, for renames :)
- willvarfar 11y ago(Mill team) On a conventional register-based OoO interrupts require issue replay and this is a major source of complexity and budget. On the Mill, which is a "belt machine", interrupts are as far as the hardware is concerned just an involuntary function call; the Mill does result replay. Regards mispredicts the Mill has a shockingly short pipeline and mispredicts (where the target is in cache) is only around 5 cycles or so. The Mill has a novel prediction mechanism called transfer prediction as covered in this talk http://millcomputing.com/topic/prediction/ http://millcomputing.com/topic/prediction/
- signa11 11y agothanks for clarification, as well as the link to the talk !
- nhaehnle 11y agoAny thoughts about debugger support on the Mill? It seems to me that this could be a bit of a headache. For example, the usual technique for breakpoints is to trigger an interrupt at the desired instruction, which then causes a context switch to the debugger process. How will the debugger be able to access all the bypass-network/belt/spiller data? My off-the-cuff thought is that since the spiller has a mechanism for dumping its state in memory anyway, there is probably (or should be) a way for software to force it to dump this state, which could be used by the debugger to read all the required data from a specified (probably model-specific) structure in memory.
- willvarfar 11y ago(Mill team) Any questions, ask away, happy to explain or dodge as appropriate ;)
- restalis 11y agoI 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 agoIf 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 agoI 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 agoThere 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.
- deleted 11y ago[deleted]
- madez 11y agoHe says that they are going to implement all instructions that are not supported by the hardware[1]. I wonder if they will use automatic synthesis of code for each instruction, and if so, how they are going to ensure good performance. Maybe superoptimization? Another question I have is about their stance on free firmware. Will the mill family members require blobs? [1] 13:50 in the linked video.