Hacker News Reader

Comment by msandford | Hacker News Reader

I suspect that they have versions of it running in FPGAs but they aren't releasing anything to a wider audience because it's an FPGA and probably 5-50x slower than it would be if it was in custom silicon.

So it's incredibly useful for them to test out ideas, but would probably garner a lot of bad impressions even if you explain "look this is super slow" because people have the idea that revolutionary is supposed to be extra fast, extenuating circumstances be damned.

View on HN

I think I remember them saying either in one of the talks or in a comment somewhere (sorry I can't be more specific), that, yes, they do have it working on an FPGA, but since the purpose is only to test the design, it doesn't run anything like impressively fast, because they aren't utilizing the resources efficiently.

EDIT: by resources, I mean, the specialized logic and chunks of RAM that exist inside FPGAs.

Found it: https://groups.google.com/forum/#!topic/comp.arch.fpga/BTojR...

If you can describe something for an FPGA it's not a huge leap to get it into silicon. A lot of people got pissed once they realized that the custom bitcoin mining ASICs were actually the open-source FPGA designs simply "burned" into an ASIC.

I suspect that the reason everything is taking so long is that they have to re-write so much of the core stuff (standard library, OS, drivers, etc). But once you can boot linux on a very slow FPGA I can't see a lot of reasons not to start making the ASICs.

One reason is of your very slow FPGA is slower than the very slow FPGA programmed to be conventional hardware.

If that happened, I would figure out why before spending $$ on that ASIC.

You are certainly right in a sense, because both FPGA and silicon is usually described using some VHDL or Verilog. So once they have a working FPGA, it's not too difficult to get it into some silicon.

However, to get it into fast and power-efficient silicon is still a ridiculous amount of work. FPGA technology is vastly different from directly designing VLSI circuits. For one thing, they'll most likely have to use different pipeline designs to squeeze the cycle times low enough.

I worry that the Mill people are vastly overconfident. There are very interesting ideas there, but I suspect that they are trying to improve so many aspects of a CPU at once that they will be unable to execute any of them well. The end result is likely that sub-par execution leads to inefficiencies that accumulate to the point where any of the theoretical advantages of their design gets overwhelmed - especially since many of their ideas can be integrated by competitors as well. That said, I'd love to be proven wrong here.

So at first I totally agreed with you, which is why I didn't post anything right away. But now that my subconscious has had a day to chew on things, I think I don't agree quite as much.

The really interesting thing about the Mill is that it does away with a HUGE portion of what a CPU does: out-of-order execution (OOE). These days the amount of die space that's dedicated to reordering and dependency checking and the commit engine is substantial, and that stuff really slows a processor down because the thing that are happening at the end of the pipeline depend on what's happening at the beginning. At 4GHz the best-case scenario the wavelength is 75mm, and the 1/4 wavelength is thus 19mm, on the order of the size of the die!

What the Mill does is push the reordering and dependency checking to the compiler so that the hardware itself is "dumb" at least insofar as not doing all the checking for OOE and multiple dispatch, etc. Further since the instructions are ordered as blocks and that blocking is done by the compiler, the processor doesn't even need any logic to assign instructions to functional units; that's done at compile time.

I agree that fast and power efficient silicon is a challenge, but again because they're not mixing execution with reasoning about execution (OOE, multiple dispatch, commit engine, etc) it's much, much easier to make the layout fast. I believe that instructions and data will flow through the Mill in a way that makes regular CPU architects envious.

I still suspect that a huge amount of the delay is due largely to the general weirdness of the architecture; it's not like an x86 to ARM port because those have a lot of the same basic assumptions baked in and the only difference is the instruction and data encoding. On the Mill few of the assumptions are the same and so you might have to re-write a LOT of code to boot a Linux kernel.

You make a very good point. I do like to give you one additional aspect to consider: While the Mill saves on instruction scheduling logic (and register renaming, and certainly also has the benefit of re-thinking opcodes and instruction decode), there are other features that add complexity again. Making a subroutine call appear as if it were a single instruction has got to be tricky, for example.

In the end, I have only seen CPU design from a physical design tool support point of view. I don't really have the necessary experience to judge the relative complexity of out-of-order+register renaming vs. whatever the Mill aims to do. You're probably right that the Mill is simpler.

Part of it is that all we really know about all this comes from a bunch of talks that focus on what the Mill looks like to the user. Who knows what their physical design story is. I just hope, for their own sake, that they have been working on that part of it for a significant amount of time as well.

> Making a subroutine call appear as if it were a single instruction has got to be tricky, for example.

I suspect they use the same machinery for that as they use for handling mispredicted control flow and interrupts/exceptions/faults.

Reply on news.ycombinator.com