Mill Computing, Inc. Forums The Mill Architecture Electron E1 if compared with Mill

  • Author
    Posts
  • EmptyBucket
    Participant
    Post count: 2
    #4012 |

    Reference:

    https://www.efficient.computer/
    So by how much Electron E1 is similar to the core idea from Mill?

  • Art
    Participant
    Post count: 13

    First, I don’t see anywhere near the level of technical detail on the efficient.computer website compared to what is on millcomputing.com . So far all I have seen on the efficient.computer website is very high level marketing fluff.

    What this appears to be to me is yet another grid style machine. The problem with those is grid reconfiguration. If not much grid reconfiguration is needed and the problem data also fits in the grid, then a grid machine can be hard to beat for those problem domains. If they have truly solved the compilation problem (and that’s a big if), that is an advantage that past grid machines did not have. That still doesn’t solve the need for mid-execution grid reconfiguration for certain general purpose code sets, which could have significant power and latency penalties.

    Both conventional CPU cores and the Mill can be placed in a grid configuration similar to what is described at a very high level about E1 cores in a fabric. Without knowing more detail about the E1 core than what is provided, not much more can be said comparing it to Mill architecture. I heard the claim that the E1 doesn’t have a program counter, but no details are given at all about how grid configuration for a program execution is done. I decline to speculate in the absence of information.

    A Mill core is not a grid, it is a statically scheduled VLIW where the outputs from one instruction bundle are directly routed to the input operands of a following instruction bundle using what we call the Belt, which logically is like a conveyor belt for results implementing in hardware Static Single Assignment (SSA for short). The Belt circuitry implementation looks the same as a register bypass circuit in a conventional X86, ARM or VLIW DSP core with belt tag numbers substituted for register numbers and it means the Mill only writes a small percentage of results to a register file, but most results are simply transferred directly to where they get consumed. Since I can find nothing specific about the organization of an E1 core, I can only surmise based on what is said that there must be a reconfigurable means to route a result from one computation unit to another. The larger the number of routing/configuration choices there are, the greater the programming flexibility of the E1 core – but also the closer that routing/configuration gets to the result routing in a Mill belt implementation, depending on the belt size of the Mill member being compared to.

    Our power efficiency claims are based on the known power efficiency of statically scheduled processors compared to dynamically scheduled out-of-order processors combined with the Belt eliminating the need for the preponderance of writes to a very power hungry, multi-ported register file. In a statically scheduled VLIW the amount of power consumed in a small software pipelined loop by instruction fetch and decode is minuscule. This is documented in current VLIW DSP processors. This software pipelined loop is likely the closest approximation to an E1 core processing data in a single configuration as described at a very high level.

  • EmptyBucket
    Participant
    Post count: 2

    How much time is yet required before you can start to sell your Mill cpu?

You must be logged in to reply to this topic.