4 ms·

You are correct that we have already taped out, though we haven't made any announcements yet, though will be talking publicly about it in the future with a big

You are correct that we have already taped out, though we haven't made any announcements yet, though will be talking publicly about it in the future with a big focus on the "magic" on the software side. You can read my comments on the Mill architecture elsewhere on HN (not a fan of stack machines), but my biggest disappointment in them is the fact that they have been working on Mill for ~10 years with a team ranging of 5 to 20 (from what I have heard) and have yet to get to silicon, while we have gone from a complete custom architectural idea to tapeout in ~11 months from closing our first seed funding. The big technical failure point for Itanium (in my opinion) is the fact that Intel took the relatively pure VLIW research by Josh Fisher @ HP Labs and tried to add a ridiculous number of features (and attempted x86 compatibility) that impacted the ability to statically schedule instructions. The resulting bastard architecture Intel called "EPIC" (rather than VLIW) had a very difficult job in getting the compiler to generate instruction parallel code since Intel added a huge amount of indeterminism into the architecture that goes against the original VLIW tenets. If your compiler has to assume the worst case latency for all instructions and memory operations, you are going to have a bad time.

white-flame 10y ago
> while we have gone from a complete custom architectural idea to tapeout in ~11 months from closing our first seed funding. To my understanding, the Mill project is not financed. They're enthusiasts working for sweat equity, and are likely going to seek (non-controlling?) investment to finally hit silicon when they're ready. For the scope of what they're doing, I think it's a defensible enough approach. It's not something that can be created in evolutionary stages; all designs of all parts need to be working together properly for there to be benefit from any part, and it's quite complex while also trying out tons of novel designs. (and the Mill isn't stack-based or stack-related. It's basically a crossbar of recent ALU/Load results being fed into further ALU/Store inputs in parallel. The belt is just some way to represent the set of recent results.)
gpderetta 10y ago
Itanium failed for the same reason every other VLIW failed as a general purpose CPU: there just isn't enough information a compile time to model the dynamic properties of a program. In fact many of Itanium additions (strange instruction packing, alias disambiguation hardware) were attempts at overcoming this issue. The only moderately successful general purpose VLIW are Conroe and the related Denver, and they use a runtime translation layer to collect the required dynamic informations.
- trsohmers 10y ago
  The vast majority of the dynamic parts of program that matter for scheduling (both when it comes to ILP/avoiding hazards within a core and when it comes to handling memory management for our scratchpad based memory system) are due to indeterminate latencies for memory accesses and executing instructions (due to variable length pipelines). Throw in horrible (for determinism) things like out of order execution and and branch prediction and no wonder a compiler can't determine things statically! While we are not really targeting general purpose (though I would say we have the capability to evolve to it in the future) it seems painfully obvious to me where these issues have been in any general-leaning VLIW attempts in the past, and I can't understand the clinging nature to bad architectural decisions in the past by hardware folks 30 years ago that could not imagine the ability of software in the future. </rant> Targeting general purpose from the get go is a bad idea, but it NOT impossible to do efficiently and without sacrificing performance. You just need a well defined and constrained architecture, and a clean way to describe it.
  - gpderetta 10y ago
    You have your causality relations reversed: the reason that branch prediction and dynamic caches exist is that because jump targets and working sets are hard to impossible to compute statically. Even in the restricted world of HPC, GPGPUs have been moving from statically scheduled exposed pipeline VLIW machies to more conventional SIMD with caches, virtual memory and branch prediction (no meaningful OoO yet as the large amount of thread parallelism can hide the memory latency). Also GPGPU have the benefit of having the large, lucrative GPU gaming market to pay for their development. How can a pure HPC machine be competitive in this market? Even for Intel Xeon Phi is more of a prestige project than actually meant to make money.
    - trsohmers 10y ago
      I've spent a long time debating with VLIW haters (that I presume you are with), but I'd love to see any citations you have for your claim that my causality is reversed, as I have a ton of evidence (to be fair not published yet) going for my side. While not as generally applicable as our architecture, you can take a look at basically any DSP from the past 15 years and see that VLIW works great from a performance and efficiency standpoint when your data is in a constrained form. We're showing that a compiler can structure a lot of different types of data (and the code required to actually operate on it) effectively if there are enough constraints on the hardware. Fairly pointless to try to convince you without documentation on hand for all parties, but hope you'll take a look in a couple of months. As far as market, we are going after a decent sized market where the customers care the most about efficiency and performance, and are not only willing but very eager to switch their current solutions for whatever is best. As the typical startup claims, we are able to do it for a fraction of the cost and in a fraction of the time as one of the big guys, and have a solution that is 10x better than is out there. NVIDIA boasts that they spent $1 Billion developing the Pascal architecture, with them selling the Tesla series GPUs for it at $5,000+ a unit. We've shown we can prototype something that can theoretically beat it for under $2 million, and our hope/bet is that we can take it to market (and actually beat it by an order of magnitude) for less than $25 million. That's just HPC, which doesn't include the very interesting high end DSP area that is now using very expensive and power hungry FPGAs for wireless baseband solutions which we think are a very good fit for us.

white-flame 10y ago

> while we have gone from a complete custom architectural idea to tapeout in ~11 months from closing our first seed funding. To my understanding, the Mill project is not financed. They're enthusiasts working for sweat equity, and are likely going to seek (non-controlling?) investment to finally hit silicon when they're ready. For the scope of what they're doing, I think it's a defensible enough approach. It's not something that can be created in evolutionary stages; all designs of all parts need to be working together properly for there to be benefit from any part, and it's quite complex while also trying out tons of novel designs. (and the Mill isn't stack-based or stack-related. It's basically a crossbar of recent ALU/Load results being fed into further ALU/Store inputs in parallel. The belt is just some way to represent the set of recent results.)

gpderetta 10y ago

Itanium failed for the same reason every other VLIW failed as a general purpose CPU: there just isn't enough information a compile time to model the dynamic properties of a program. In fact many of Itanium additions (strange instruction packing, alias disambiguation hardware) were attempts at overcoming this issue. The only moderately successful general purpose VLIW are Conroe and the related Denver, and they use a runtime translation layer to collect the required dynamic informations.

trsohmers 10y ago
The vast majority of the dynamic parts of program that matter for scheduling (both when it comes to ILP/avoiding hazards within a core and when it comes to handling memory management for our scratchpad based memory system) are due to indeterminate latencies for memory accesses and executing instructions (due to variable length pipelines). Throw in horrible (for determinism) things like out of order execution and and branch prediction and no wonder a compiler can't determine things statically! While we are not really targeting general purpose (though I would say we have the capability to evolve to it in the future) it seems painfully obvious to me where these issues have been in any general-leaning VLIW attempts in the past, and I can't understand the clinging nature to bad architectural decisions in the past by hardware folks 30 years ago that could not imagine the ability of software in the future. </rant> Targeting general purpose from the get go is a bad idea, but it NOT impossible to do efficiently and without sacrificing performance. You just need a well defined and constrained architecture, and a clean way to describe it.
- gpderetta 10y ago
  You have your causality relations reversed: the reason that branch prediction and dynamic caches exist is that because jump targets and working sets are hard to impossible to compute statically. Even in the restricted world of HPC, GPGPUs have been moving from statically scheduled exposed pipeline VLIW machies to more conventional SIMD with caches, virtual memory and branch prediction (no meaningful OoO yet as the large amount of thread parallelism can hide the memory latency). Also GPGPU have the benefit of having the large, lucrative GPU gaming market to pay for their development. How can a pure HPC machine be competitive in this market? Even for Intel Xeon Phi is more of a prestige project than actually meant to make money.
  - trsohmers 10y ago
    I've spent a long time debating with VLIW haters (that I presume you are with), but I'd love to see any citations you have for your claim that my causality is reversed, as I have a ton of evidence (to be fair not published yet) going for my side. While not as generally applicable as our architecture, you can take a look at basically any DSP from the past 15 years and see that VLIW works great from a performance and efficiency standpoint when your data is in a constrained form. We're showing that a compiler can structure a lot of different types of data (and the code required to actually operate on it) effectively if there are enough constraints on the hardware. Fairly pointless to try to convince you without documentation on hand for all parties, but hope you'll take a look in a couple of months. As far as market, we are going after a decent sized market where the customers care the most about efficiency and performance, and are not only willing but very eager to switch their current solutions for whatever is best. As the typical startup claims, we are able to do it for a fraction of the cost and in a fraction of the time as one of the big guys, and have a solution that is 10x better than is out there. NVIDIA boasts that they spent $1 Billion developing the Pascal architecture, with them selling the Tesla series GPUs for it at $5,000+ a unit. We've shown we can prototype something that can theoretically beat it for under $2 million, and our hope/bet is that we can take it to market (and actually beat it by an order of magnitude) for less than $25 million. That's just HPC, which doesn't include the very interesting high end DSP area that is now using very expensive and power hungry FPGAs for wireless baseband solutions which we think are a very good fit for us.