8 ms·

“The Mill” – It just might Work

274 points by dochtman 13y ago

Xdes 13y ago
Can't wait to buy a Mill and mess around with it. Hopefully it isn't more expensive than current desktop or server processors.
DiabloD3 13y ago
I want to replace every computer in the world with this.
dochtman 13y ago
I wonder what the compilers would be like. If these guys contribute, say, an LLVM backend, that would make it so much easier to support.
- willvarfar 13y ago
  (Mill team) We are in fact working on an LLVM backend right now. This will generate Mill IR, which will be 'specialised' on-target so will run on all Mill family members.
  - pron 13y ago
    How about a JVM?
    - MrBuddyCasino 13y ago
      Yes please. Its a stack machine anyway, so it should map nicely to the hardware right?
      - gnmj 13y ago
        Can't wait for Mill on Rails as well.
      - Mindless2112 13y ago
        The Mill is closer to a queue machine [1] than a stack machine. [1] http://en.wikipedia.org/wiki/Queue_automaton http://en.wikipedia.org/wiki/Queue_automaton
    - jerven 13y ago
      Seems much more sensible as a quicker commercialization approach. Java code does not depend on hardware memory models but a defined memory model. Much easier to validate your jvm is valid than all C programs that clients might want to run. You could even have mills cpus on PCI cards in a standard X86 machine, where the java executable passes the program to the the mills on the PCI to run. A bit like how Azul and their vega machines worked (although those where network attached).
  - dochtman 13y ago
    Will you contribute it to upstream, or keep it closed source?
    - ape4 13y ago
      No good reason to make it closed source. Any users would need Mill hardware.
      - dochtman 13y ago
        icc isn't open source, is it?
        twic 13y ago
        I always assumed that the parts of icc that Intel want to keep secret aren't in the backend, they're in the optimisation phases, which could be ported to compilers for other architectures.
        bri3d 13y ago
        Intel are in a perpetual war with another vendor with the same instruction set for which some of their optimizations are generally applicable, to the point that ICC used to intentionally cripple AMD hardware: http://www.agner.org/optimize/blog/read.php?i=49#49 http://www.agner.org/optimize/blog/read.php?i=49#49 Thus there's a disincentive for Intel to release their optimizer's tricks: not only are at least some percentage of the optimizations applicable to their competitor's microarchitecture implementing the same ISA, but they probably reveal various Intel CPU internals that Intel consider trade secrets (similar to the argument against open-sourcing 3D drivers and shader compilers). Mill is not going to be locked into a bitter head-to-head battle with someone else trying to implement the same ISA better (at least not for a long time), so there's no incentive for them to hide their CPU's internal optimizations and no competition for which compiler optimizations could be generally applicable.
    - igodard 13y ago
      Contribute it.
  - Filligree 13y ago
    Wait, does this mean your approach to static scheduling is in fact just-in-time compilation? Nifty, I can see how that would work. :)
comatose_kid 13y ago
I worked on a VLIW processor long ago and it had a theoretical peak of 700 MIPS (iirc) back in 2000. It was a neat architecture but required fairly low level knowledge to get the most out of it.
- dman 13y ago
  Any pointers to write ups about this?
- shavenwarthog2 13y ago
  Sounds like the Intel i860 from the late 1990s. Frighteningly fast VLIW in theory, but in practice not so much. I think untweaked code ran at 3% of max speed.
  - DiabloD3 13y ago
    The problem there is, Intel intentionally kills any non-x86 Intel arch. For example, the Itanium was brilliant, and then they repeatedly threw it under the bus until people hated it.
    - gnaffle 13y ago
      That's not really how the story goes, though. Intel spent a lot of effort on getting Itanium to succeed, and they really dragged their feet into x86-64. It was the market that decided that the price/performance of Itanium wasn't worth it.
      - DiabloD3 13y ago
        Thats how a lot of people tell the story, but I just don't agree with it. There is zero evidence that the market killed Itanium when Intel was already trying to kill it because it was eating into Xeon sales on high end platforms.
Brashman 13y ago
What differentiates Mill with Itanium? Also, what are the 2.3x power/performance improvements based on? Is there silicon for this?
- gnoway 13y ago
  I'm actually wondering where the 2.3x number he cites is coming from. I don't believe the Mill team is claiming 2.3x performance advantage over Haswell while using 2.3x less power, which is how I read that comment. I watched the replay of the Execution talk here: http://millcomputing.com/docs/execution/ http://millcomputing.com/docs/execution/ I'd recommend watching all of the talks if you have the time. In this talk, maybe 2/3-3/4 of the way through, Godard made a claim about performance relative to OOO, 'like a Haswell' or Haswell specifically - can't remember which, and I can't go through the video again right now. He said something to the effect that they would approach performance for {OOO|~Haswell|Haswell} using less power. It was a very general statement, which I took to mean that a Mill family member intended for GP PC desktop use could approach - not match or exceed - performance of a typical GP PC desktop processor while using less power. Which is certainly not something we've never heard before. And I think the statement is coming from theoretical calculation. As far as difference with Itanium: I don't know anything about processor design, but I am pretty certain the belt concept central to the Mill is not applied in the Itanium/EPIC. I think it's likely that the Mill is intended to support more operations per instruction than Itanium. The other thing is that there is not 'The Mill Processor' - it's more of a design scheme and ISA.
  - igodard 13y ago
    It would be nice if there were a single number that could be justified by measurement, but there's no hardware yet to measure and there would not be a single number even if the hardware existed. That's because there's not just one "Mill", it's a family. What we can say is that for equivalent computation capacity (i.e. number of functional units) the Mill will give somewhat better performance at much better power. Internally, the Mill's power budget is essentially the same as that of a DSP with the same function capacity, because they work in much the same way. DSPs have been around for a long time, and the power/performance comparisons with OOO have been long published. For equal process and equal Mips capacity the power difference for the core is 8-12x better than OOO, and we expect to do at least as well. That's for equal compute capacity. Every architecture has a cap on scaling compute capacity. The cap seems to be around 8 pipelines in OOO machines; try to add more and you just slow down everything more than you gain from the extra pipes. The Mill has caps too. We don't know yet where the diminishing returns point will be in detail, but our sims and engineering expertise suggests that it will be somewhere in the 30-40 pipes region. Such a high-end Mill would swap a good deal - but not all - of its power advantage for more horsepower. You have the inverse story at the low end of the family: the lowest Mill has only five pipes, and no floating point at all. Not barn-burning performance, but much lower power even than existing non-OOO offerings. So there's no one number, and no hard measurements anyway. If you doubt our projections then you are entitled to your opinion; in fact there's a fair amount of disagreement even within the Mill team as to what we will see in the actual chip. But the team includes quite a few who have been doing this for years, and in several cases were involved in the creation of the chips that you would compare the Mill against, so their considered opinion should not be rejected out of hand.
dkhenry 13y ago
So where do I buy one and test it myself. I love the theory, and some of the claims are awesome, but I am reminded of the Cell-BE and the chatter around it at release time. It wasen't untill we got the Cell into the hands of developers that we learned it's real limitations. I want a Mill I can write programs for and run benchmarks against. My benchmarks on my bench.
- bryanlarsen 13y ago
  If they raise the money they're looking for, you should be able to do that in 2 to 3 years. http://electronics360.globalspec.com/article/3843/startup-seeks-funds-to-realize-belt-processor http://electronics360.globalspec.com/article/3843/startup-se...
  - pdq 13y ago
    3 years is a bare minimum. They would need to staff up hardware design, verification, performance modelers, compiler writers, OS and software teams, and license all the necessary EDA software (simulators, waveform viewers, etc). My guess would be a minimum $20 million to get it to a solid FPGA prototype in 3 years. Then if that were successful they could spent another $25 million and get it into silicon at a good process (20nm or below).
Symmetry 13y ago
It's really exciting, but here are a few worries I have about their ability to meet their performance claims: 1) I don't see that they'll be able to save much power on their cache hierarchy relative to conventional machines. Sure, backless memory will save them some traffic but on the other hand they won't e able to take advantage of the sorts of immense optimization resources that Intel has, so that fraction of chip power to performance isn't going away. 2) The bypass network on a conventional out of order chip takes up an amount of power similar to the execution units, and I expect that the Mill's belt will be roughly equivalent. 3) I'm worried on the software front. The differences between how they and LLVM handle pointer is causing them trouble, and porting an OS to the Mill looks to be a pretty complicated business compared to most other architectures. It's certainly not impossible, but it's still a big problem if they're worried about adoption. All of which is to say, I think the 10x they're talking about is unrealistic. The Mill is full of horribly clever ideas which I'm really excited about and I do think their approach seems workable and advantageous, but I'd expect 3x at most when they've had time to optimize. The structures in a modern CPU that provide out of order execution and the top-level TLB are big and power hungry, but they're not 90% of power use. If they're going to hit it big they'll probably start out in high-end embedded. Anything where you have a RTOS running on a fast processor, and your set of software is small enough that porting it all isn't a big problem. Also, the metadata isn't like a None in Python, it's like a Maybe in Haskell! You can string them together and only throw an exception on side effects in a way that makes speculation (and vector operation) in this machine much nicer. EDIT: Whatever the result of the Mill itself, it contains a large number of astoundingly clever ideas some of which would be useful even without all the other ideas. Like you could drop in Mill load semantics to most in-order processors and you'd have to do something different with how they interact with function calls but it would still be pretty useful. EDIT2: I may sound pessimistic above, but I would still totally give them money if I were a registered investor. The outside view just says that new processors that try to change lots of things at once is pretty bad even if, on the inside view, they have a good story for how their going to overcome the challenges they'll face.
- rst 13y ago
  One tricky issue in porting an existing OS to the Mill is their AS/400-style portability strategy (as outlined by Godard in the comments): binaries are distributed as "Mill IR", and compiled to local binary, which gets cached for the next execution. The problem is where to put this cache, and how the OS deals with it. Say, for example, you put the cache in the file system. OK, who has write permission, and can the "cached local binary" be written on first execution by a user who doesn't have write permission on the binary being "localized"? (Or could the translator be run on "apt-get install ..." --- and if so, who trains apt to do that?) And so forth. Putting the cache someplace that is hidden from the "normal" OS is possible, but that has problems, too. At the very least, you'd need to figure out what to do if the hidden whatever-it-is runs out of space. (And how doing I/O to it would interfere with other OS-level performance optimizations, like scheduling of disk seeks.) IBM could finesse these problems on the AS/400 because they controlled everything about it, hardware to OS to UI. And there are niches with high performance requirements that could live with a nonstandard OS. But for general-purpose computing, it could get awkward. (Perhaps awkward enough to consider TransMeta's strategy of doing JIT translation to actual machine instructions, which let them keep the "real instruction" cache entirely in dedicated RAM --- though that has problems too.)
rayiner 13y ago
This is a detailed description of the architecture: http://millcomputing.com/topic/introduction-to-the-mill-cpu-programming-model-2 http://millcomputing.com/topic/introduction-to-the-mill-cpu-.... It describes Mill's approach to specifying inter-instruction dependencies, grouping instructions, and handling variable-latency memory instructions.
ChuckMcM 13y ago
I am really rooting for these folks, after going to a talk on it last year about this time and trying to everything thing I could to pick it apart (they had good answers for all my questions) I felt confident that its going to be a pretty awesome architecture. Assuming that reducing to practice all of their great ideas doesn't reveal some amazing 'gotcha', I'm hoping to get an eval system. The thing I'm most closely watching are the compiler stuff since this was such a huge issue on Itanium (literally 6x difference in code execution speed just from compiler changes) and putting some structured data (pointer chasing) type applications through their paces which is always a good way to flush out memory/cpu bottlenecks.
- pjmlp 13y ago
  From the posts on Reddit they are saying their compiler is based in a JIT architecture similar to how mainframes work. Basically doing AOT compilation and optimizations on installation, but they have postponed more information to an upcoming talk.
  - igodard 13y ago
    Not quite: only scheduling and binary creation is done at install time. Instruction selection and optimization is done during compilation in the usual way.
    - pjmlp 13y ago
      Thanks for the hint.
WhitneyLand 13y ago
Who is this guy? Where can you teach post-doc computer science without ever having taken a course in CS, let alone a degree? Obviously a degree is not a necessary condition for success and it's always bothered me that people like Michael Faraday had to battle academic and class prejudice before changing the world. However I don't think it's unreasonable to see a bio of past projects/companies/research papers. "Despite having taught Computer Science at the graduate and post-doctorate levels, he has no degrees and has never taken a course in Computer Science"
- WhitneyLand 13y ago
  Why the downvote? It just seems to be an unusual bio and would be interesting to see the history leading up the mill: http://www.ftpress.com/authors/bio.aspx?a=DE5F140D-E5BF-4E83-B020-1DB28A80B71C http://www.ftpress.com/authors/bio.aspx?a=DE5F140D-E5BF-4E83...
  - baking 13y ago
    He was on THE "green team" you young whipper-snapper and before that he worked on Mary and Mary2, languages from the long lost mists of time. After a certain point you don't need to go to school and people start asking you to teach them.
- igodard 13y ago
  My first compiler (still in use) was for the Burroughs B6500 mainframe in 1970. During my brief and inglorious college career I did not take a CS class. In fact, there were no CS classes. The college didn't even own a computer. Yes, there were such times, in living memory, hard as it may be to imagine. These days you need a union card (i.e. a CS degree) to get a job. That's a shame. I've been refused a university position for lack of a PhD - to teach a subject that I largely invented. There's something wrong with that. We have no such requirements on the Mill team.
  - DSingularity 13y ago
    Indeed there is something wrong here. I am sure it isn't easy to identify those with scholarly authority. Sad to see that they are missing it. That being said, you are still having scholarly impact! Your talks have taught me to question all my fundamental assumptions when it comes to architecture, compilers, and computing! I love following your peoples work, and I can't wait to see its product!
cromwellian 13y ago
I actually had high hopes for Sun's Rock architecture, which had a rather elegant hardware-scout/speculative threading system to hide memory latencies, and instead of a reorder-buffer they had a neat checkpoint table, that simultaneously gave you out of order retirement, as well as hardware support for software transactional memory. Alas, it looked good on paper, but died in practice, either because the theory was flawed (but academic simulations seemed to suggest it would be a win), or because Sun didn't have the resources to invest in it properly and Oracle killed it. Claiming a breakthrough in VLIW static scheduling that yields 2.3x seems interesting, but the reality made be different, not to mention what kinds of workloads would get these speedups. If you compare the way NVidia and AMD's GPUs work, in particular AMD's, they rely heavily on static analysis, but in the end, extracting max performance is highly dependent on structuring your workload to deal with the way the underlying architecture executes kernels. If it turns out you have to actually restructure your code to get this 2.3x performance, rather than gcc-recompile with a different architecture, then it's not really an apples-to-apples speedup.
- cpleppert 13y ago
  >>Alas, it looked good on paper, but died in practice, either because the theory was flawed (but academic simulations seemed to suggest it would be a win), or because Sun didn't have the resources to invest in it properly and Oracle killed it. I heard this never actually worked at all and they added the ability to turn off the hardware scout entirely before canceling it. I'm not really sure how the scout was supposed to be able to help performance. If the algorithm is indirect heavy then speculatively running it won't help you. On the other hand, if it isn't you might as well rely on conventional prefetch. Do you have a link to those studies? >> If it turns out you have to actually restructure your code to get this 2.3x performance, rather than gcc-recompile with a different architecture, then it's not really an apples-to-apples speedup. Right, I would only add that the algorithm itself has to be amenable to that architecture in the first place. Most general purpose code isn't and won't be able to take advantage of a large number of parallel execution resources.
- bcantrill 13y ago
  Having been at Sun and having been (too) intimately involved with the microprocessor side of the house for way too damn long, I can tell you that when it came to microprocessors, Sun was all vision and no execution. The theme that was repeated over several microprocessors: a new, big idea that made all of the DEs horny, but that proved annoyingly tricky to implement. Sacrifices would then be made elsewhere in order to make a tape out date and/or power or die budget. But these sacrifices would be made without a real understanding of the consequences -- and the chip would arrive severely compromised. (Or wouldn't arrive at all.) Examples abound but include Viking, Cheetah, UltraJava/NanoJava/PicoJava, MAJC, Millennium (cancelled), Niagara (shared FPU!) and ROC (originally "Regatta-on-a-chip", but became "Rock" only when it was clear that it was going to be so late that it wasn't going to be meaningfully competing with IBM's Regatta after all). The only microprocessor that Sun really got unequivocally right (on time, on budget, leading performance, basically worked) was Spitfire -- but even then, on the subsequent shrinks (Blackbird and beyond) the grievous e-cache design flaws basically killed it. Point is: in microprocessors, execution isn't everything -- it's the only thing.
al2o3cr 13y ago
Verilog or GTFO.
panduwana 13y ago
If the belt operation can be changed from the current "take any two items on belt, process them, put the result to the front of belt" to "take two front-most items on belt, process them, put the result anywhere on belt", we can save some bits and make shorter instructions (good for mobile): currently: OP load-address-1 load-address-2 // output is always put at belt's front to: OP store-address // inputs are always 2 frontmost items on belt
- willvarfar 13y ago
  (See The Belt talk for an explanation of belt vs stack)
- axman6 13y ago
  How do you get ILP from this? Seems like it would make scheduling much more difficult because you now need to make sure that that the results you need for each instruction are in the order in the belt you need, and you have to be able to execute any order of instruction types. The mill can run fast partly because and instruction can use any result on the belt, and similar instructions are grouped together making decode simpler (from memory, they have two separate decoders and each instruction has all say arith instructions grouped and decoded by one decode, and all the others decoded by the other). Basically, I don't see how you can use what you suggest to do, in one instruction: [ add positions 7 and 5 | multiply positions 7 and 2 | call f on 4 and 5 | branch to foo if position 3 was LT else bar ] ending up with the belt [ [7]+[5], [7]*[2], f([4],[5]) ... ] or whatever you like. All you need to do to schedule the mill is to perform as many operations in parallel as the hardware can do, and then find out where their results would be placed to create the next instruction.
  - panduwana 13y ago
    In the linked article it is said that "According to prior research, only some 13% of values are used more than once". So based on the research on which Mill is based on, your example and that "instruction can use any result on the belt" is actually minority case. As for scheduling my proposed store-addressed belt: you perform as many operations in parallel, then for each operation find the other operation that depends on the former's operation result, calculate the distance between them and assign it as the former's store address. The compiler has more work to do yes, but not "much more difficult".
vietor 13y ago
It's easy* to build a dramatically better performing and more efficient CPU than currently available if you don't have to restrict yourself to the code and compilers currently available. The exciting thing to me is that between wider availability of open source compilers and code, and a larger amount of user level code being written in interpreted languages (so only the language runtime needs to be rebuilt), there might actually be a future in alternative architectures. * As these things go...
nly 13y ago
My biggest concern is Intel will just buy and bury it.
- DiabloD3 13y ago
  OOB is unlikely to ever sell.
JoeAltmaier 13y ago
How is this different from a convention register model, where the compiler stores each result into a new register round-robin? That would be a belt too.
- axman6 13y ago
  That works fine until you have things like branches and function calls. Most call conventions specify which registers arguments are in, and with what you're proposing each function call needs to know where it is up to in the rotation at the beginning of the call. If the ahrdware looks after it (either through a index register that stores the position of the next write), then it becomes easier; but no one's doing that, and afaik, the mill is the first machine to do anything close. Stack machines are sort of similar, but word differently because they need to remember all values on the stack untill they're popped. The mill just forgets old results and the compiler must make sure they're still available when they're needed later.
klausnrooster 13y ago
Soon with Memristor RAM/SSD!

274 points by dochtman 13y ago

Xdes 13y ago

Can't wait to buy a Mill and mess around with it. Hopefully it isn't more expensive than current desktop or server processors.

DiabloD3 13y ago

I want to replace every computer in the world with this.

dochtman 13y ago

I wonder what the compilers would be like. If these guys contribute, say, an LLVM backend, that would make it so much easier to support.

willvarfar 13y ago
(Mill team) We are in fact working on an LLVM backend right now. This will generate Mill IR, which will be 'specialised' on-target so will run on all Mill family members.
- pron 13y ago
  How about a JVM?
  - MrBuddyCasino 13y ago
    Yes please. Its a stack machine anyway, so it should map nicely to the hardware right?
    - gnmj 13y ago
      Can't wait for Mill on Rails as well.
    - Mindless2112 13y ago
      The Mill is closer to a queue machine [1] than a stack machine. [1] http://en.wikipedia.org/wiki/Queue_automaton http://en.wikipedia.org/wiki/Queue_automaton
  - jerven 13y ago
    Seems much more sensible as a quicker commercialization approach. Java code does not depend on hardware memory models but a defined memory model. Much easier to validate your jvm is valid than all C programs that clients might want to run. You could even have mills cpus on PCI cards in a standard X86 machine, where the java executable passes the program to the the mills on the PCI to run. A bit like how Azul and their vega machines worked (although those where network attached).
- dochtman 13y ago
  Will you contribute it to upstream, or keep it closed source?
  - ape4 13y ago
    No good reason to make it closed source. Any users would need Mill hardware.
    - dochtman 13y ago
      icc isn't open source, is it?
      - twic 13y ago
        I always assumed that the parts of icc that Intel want to keep secret aren't in the backend, they're in the optimisation phases, which could be ported to compilers for other architectures.
      - bri3d 13y ago
        Intel are in a perpetual war with another vendor with the same instruction set for which some of their optimizations are generally applicable, to the point that ICC used to intentionally cripple AMD hardware: http://www.agner.org/optimize/blog/read.php?i=49#49 http://www.agner.org/optimize/blog/read.php?i=49#49 Thus there's a disincentive for Intel to release their optimizer's tricks: not only are at least some percentage of the optimizations applicable to their competitor's microarchitecture implementing the same ISA, but they probably reveal various Intel CPU internals that Intel consider trade secrets (similar to the argument against open-sourcing 3D drivers and shader compilers). Mill is not going to be locked into a bitter head-to-head battle with someone else trying to implement the same ISA better (at least not for a long time), so there's no incentive for them to hide their CPU's internal optimizations and no competition for which compiler optimizations could be generally applicable.
  - igodard 13y ago
    Contribute it.
- Filligree 13y ago
  Wait, does this mean your approach to static scheduling is in fact just-in-time compilation? Nifty, I can see how that would work. :)

comatose_kid 13y ago

I worked on a VLIW processor long ago and it had a theoretical peak of 700 MIPS (iirc) back in 2000. It was a neat architecture but required fairly low level knowledge to get the most out of it.

dman 13y ago
Any pointers to write ups about this?
shavenwarthog2 13y ago
Sounds like the Intel i860 from the late 1990s. Frighteningly fast VLIW in theory, but in practice not so much. I think untweaked code ran at 3% of max speed.
- DiabloD3 13y ago
  The problem there is, Intel intentionally kills any non-x86 Intel arch. For example, the Itanium was brilliant, and then they repeatedly threw it under the bus until people hated it.
  - gnaffle 13y ago
    That's not really how the story goes, though. Intel spent a lot of effort on getting Itanium to succeed, and they really dragged their feet into x86-64. It was the market that decided that the price/performance of Itanium wasn't worth it.
    - DiabloD3 13y ago
      Thats how a lot of people tell the story, but I just don't agree with it. There is zero evidence that the market killed Itanium when Intel was already trying to kill it because it was eating into Xeon sales on high end platforms.

Brashman 13y ago

What differentiates Mill with Itanium? Also, what are the 2.3x power/performance improvements based on? Is there silicon for this?

gnoway 13y ago
I'm actually wondering where the 2.3x number he cites is coming from. I don't believe the Mill team is claiming 2.3x performance advantage over Haswell while using 2.3x less power, which is how I read that comment. I watched the replay of the Execution talk here: http://millcomputing.com/docs/execution/ http://millcomputing.com/docs/execution/ I'd recommend watching all of the talks if you have the time. In this talk, maybe 2/3-3/4 of the way through, Godard made a claim about performance relative to OOO, 'like a Haswell' or Haswell specifically - can't remember which, and I can't go through the video again right now. He said something to the effect that they would approach performance for {OOO|~Haswell|Haswell} using less power. It was a very general statement, which I took to mean that a Mill family member intended for GP PC desktop use could approach - not match or exceed - performance of a typical GP PC desktop processor while using less power. Which is certainly not something we've never heard before. And I think the statement is coming from theoretical calculation. As far as difference with Itanium: I don't know anything about processor design, but I am pretty certain the belt concept central to the Mill is not applied in the Itanium/EPIC. I think it's likely that the Mill is intended to support more operations per instruction than Itanium. The other thing is that there is not 'The Mill Processor' - it's more of a design scheme and ISA.
- igodard 13y ago
  It would be nice if there were a single number that could be justified by measurement, but there's no hardware yet to measure and there would not be a single number even if the hardware existed. That's because there's not just one "Mill", it's a family. What we can say is that for equivalent computation capacity (i.e. number of functional units) the Mill will give somewhat better performance at much better power. Internally, the Mill's power budget is essentially the same as that of a DSP with the same function capacity, because they work in much the same way. DSPs have been around for a long time, and the power/performance comparisons with OOO have been long published. For equal process and equal Mips capacity the power difference for the core is 8-12x better than OOO, and we expect to do at least as well. That's for equal compute capacity. Every architecture has a cap on scaling compute capacity. The cap seems to be around 8 pipelines in OOO machines; try to add more and you just slow down everything more than you gain from the extra pipes. The Mill has caps too. We don't know yet where the diminishing returns point will be in detail, but our sims and engineering expertise suggests that it will be somewhere in the 30-40 pipes region. Such a high-end Mill would swap a good deal - but not all - of its power advantage for more horsepower. You have the inverse story at the low end of the family: the lowest Mill has only five pipes, and no floating point at all. Not barn-burning performance, but much lower power even than existing non-OOO offerings. So there's no one number, and no hard measurements anyway. If you doubt our projections then you are entitled to your opinion; in fact there's a fair amount of disagreement even within the Mill team as to what we will see in the actual chip. But the team includes quite a few who have been doing this for years, and in several cases were involved in the creation of the chips that you would compare the Mill against, so their considered opinion should not be rejected out of hand.

dkhenry 13y ago

So where do I buy one and test it myself. I love the theory, and some of the claims are awesome, but I am reminded of the Cell-BE and the chatter around it at release time. It wasen't untill we got the Cell into the hands of developers that we learned it's real limitations. I want a Mill I can write programs for and run benchmarks against. My benchmarks on my bench.

bryanlarsen 13y ago
If they raise the money they're looking for, you should be able to do that in 2 to 3 years. http://electronics360.globalspec.com/article/3843/startup-seeks-funds-to-realize-belt-processor http://electronics360.globalspec.com/article/3843/startup-se...
- pdq 13y ago
  3 years is a bare minimum. They would need to staff up hardware design, verification, performance modelers, compiler writers, OS and software teams, and license all the necessary EDA software (simulators, waveform viewers, etc). My guess would be a minimum $20 million to get it to a solid FPGA prototype in 3 years. Then if that were successful they could spent another $25 million and get it into silicon at a good process (20nm or below).

Symmetry 13y ago

It's really exciting, but here are a few worries I have about their ability to meet their performance claims: 1) I don't see that they'll be able to save much power on their cache hierarchy relative to conventional machines. Sure, backless memory will save them some traffic but on the other hand they won't e able to take advantage of the sorts of immense optimization resources that Intel has, so that fraction of chip power to performance isn't going away. 2) The bypass network on a conventional out of order chip takes up an amount of power similar to the execution units, and I expect that the Mill's belt will be roughly equivalent. 3) I'm worried on the software front. The differences between how they and LLVM handle pointer is causing them trouble, and porting an OS to the Mill looks to be a pretty complicated business compared to most other architectures. It's certainly not impossible, but it's still a big problem if they're worried about adoption. All of which is to say, I think the 10x they're talking about is unrealistic. The Mill is full of horribly clever ideas which I'm really excited about and I do think their approach seems workable and advantageous, but I'd expect 3x at most when they've had time to optimize. The structures in a modern CPU that provide out of order execution and the top-level TLB are big and power hungry, but they're not 90% of power use. If they're going to hit it big they'll probably start out in high-end embedded. Anything where you have a RTOS running on a fast processor, and your set of software is small enough that porting it all isn't a big problem. Also, the metadata isn't like a None in Python, it's like a Maybe in Haskell! You can string them together and only throw an exception on side effects in a way that makes speculation (and vector operation) in this machine much nicer. EDIT: Whatever the result of the Mill itself, it contains a large number of astoundingly clever ideas some of which would be useful even without all the other ideas. Like you could drop in Mill load semantics to most in-order processors and you'd have to do something different with how they interact with function calls but it would still be pretty useful. EDIT2: I may sound pessimistic above, but I would still totally give them money if I were a registered investor. The outside view just says that new processors that try to change lots of things at once is pretty bad even if, on the inside view, they have a good story for how their going to overcome the challenges they'll face.

rst 13y ago
One tricky issue in porting an existing OS to the Mill is their AS/400-style portability strategy (as outlined by Godard in the comments): binaries are distributed as "Mill IR", and compiled to local binary, which gets cached for the next execution. The problem is where to put this cache, and how the OS deals with it. Say, for example, you put the cache in the file system. OK, who has write permission, and can the "cached local binary" be written on first execution by a user who doesn't have write permission on the binary being "localized"? (Or could the translator be run on "apt-get install ..." --- and if so, who trains apt to do that?) And so forth. Putting the cache someplace that is hidden from the "normal" OS is possible, but that has problems, too. At the very least, you'd need to figure out what to do if the hidden whatever-it-is runs out of space. (And how doing I/O to it would interfere with other OS-level performance optimizations, like scheduling of disk seeks.) IBM could finesse these problems on the AS/400 because they controlled everything about it, hardware to OS to UI. And there are niches with high performance requirements that could live with a nonstandard OS. But for general-purpose computing, it could get awkward. (Perhaps awkward enough to consider TransMeta's strategy of doing JIT translation to actual machine instructions, which let them keep the "real instruction" cache entirely in dedicated RAM --- though that has problems too.)

rayiner 13y ago

This is a detailed description of the architecture: http://millcomputing.com/topic/introduction-to-the-mill-cpu-programming-model-2 http://millcomputing.com/topic/introduction-to-the-mill-cpu-.... It describes Mill's approach to specifying inter-instruction dependencies, grouping instructions, and handling variable-latency memory instructions.

ChuckMcM 13y ago

I am really rooting for these folks, after going to a talk on it last year about this time and trying to everything thing I could to pick it apart (they had good answers for all my questions) I felt confident that its going to be a pretty awesome architecture. Assuming that reducing to practice all of their great ideas doesn't reveal some amazing 'gotcha', I'm hoping to get an eval system. The thing I'm most closely watching are the compiler stuff since this was such a huge issue on Itanium (literally 6x difference in code execution speed just from compiler changes) and putting some structured data (pointer chasing) type applications through their paces which is always a good way to flush out memory/cpu bottlenecks.

pjmlp 13y ago
From the posts on Reddit they are saying their compiler is based in a JIT architecture similar to how mainframes work. Basically doing AOT compilation and optimizations on installation, but they have postponed more information to an upcoming talk.
- igodard 13y ago
  Not quite: only scheduling and binary creation is done at install time. Instruction selection and optimization is done during compilation in the usual way.
  - pjmlp 13y ago
    Thanks for the hint.

WhitneyLand 13y ago

Who is this guy? Where can you teach post-doc computer science without ever having taken a course in CS, let alone a degree? Obviously a degree is not a necessary condition for success and it's always bothered me that people like Michael Faraday had to battle academic and class prejudice before changing the world. However I don't think it's unreasonable to see a bio of past projects/companies/research papers. "Despite having taught Computer Science at the graduate and post-doctorate levels, he has no degrees and has never taken a course in Computer Science"

WhitneyLand 13y ago
Why the downvote? It just seems to be an unusual bio and would be interesting to see the history leading up the mill: http://www.ftpress.com/authors/bio.aspx?a=DE5F140D-E5BF-4E83-B020-1DB28A80B71C http://www.ftpress.com/authors/bio.aspx?a=DE5F140D-E5BF-4E83...
- baking 13y ago
  He was on THE "green team" you young whipper-snapper and before that he worked on Mary and Mary2, languages from the long lost mists of time. After a certain point you don't need to go to school and people start asking you to teach them.
igodard 13y ago
My first compiler (still in use) was for the Burroughs B6500 mainframe in 1970. During my brief and inglorious college career I did not take a CS class. In fact, there were no CS classes. The college didn't even own a computer. Yes, there were such times, in living memory, hard as it may be to imagine. These days you need a union card (i.e. a CS degree) to get a job. That's a shame. I've been refused a university position for lack of a PhD - to teach a subject that I largely invented. There's something wrong with that. We have no such requirements on the Mill team.
- DSingularity 13y ago
  Indeed there is something wrong here. I am sure it isn't easy to identify those with scholarly authority. Sad to see that they are missing it. That being said, you are still having scholarly impact! Your talks have taught me to question all my fundamental assumptions when it comes to architecture, compilers, and computing! I love following your peoples work, and I can't wait to see its product!

cromwellian 13y ago

I actually had high hopes for Sun's Rock architecture, which had a rather elegant hardware-scout/speculative threading system to hide memory latencies, and instead of a reorder-buffer they had a neat checkpoint table, that simultaneously gave you out of order retirement, as well as hardware support for software transactional memory. Alas, it looked good on paper, but died in practice, either because the theory was flawed (but academic simulations seemed to suggest it would be a win), or because Sun didn't have the resources to invest in it properly and Oracle killed it. Claiming a breakthrough in VLIW static scheduling that yields 2.3x seems interesting, but the reality made be different, not to mention what kinds of workloads would get these speedups. If you compare the way NVidia and AMD's GPUs work, in particular AMD's, they rely heavily on static analysis, but in the end, extracting max performance is highly dependent on structuring your workload to deal with the way the underlying architecture executes kernels. If it turns out you have to actually restructure your code to get this 2.3x performance, rather than gcc-recompile with a different architecture, then it's not really an apples-to-apples speedup.

cpleppert 13y ago
>>Alas, it looked good on paper, but died in practice, either because the theory was flawed (but academic simulations seemed to suggest it would be a win), or because Sun didn't have the resources to invest in it properly and Oracle killed it. I heard this never actually worked at all and they added the ability to turn off the hardware scout entirely before canceling it. I'm not really sure how the scout was supposed to be able to help performance. If the algorithm is indirect heavy then speculatively running it won't help you. On the other hand, if it isn't you might as well rely on conventional prefetch. Do you have a link to those studies? >> If it turns out you have to actually restructure your code to get this 2.3x performance, rather than gcc-recompile with a different architecture, then it's not really an apples-to-apples speedup. Right, I would only add that the algorithm itself has to be amenable to that architecture in the first place. Most general purpose code isn't and won't be able to take advantage of a large number of parallel execution resources.
bcantrill 13y ago
Having been at Sun and having been (too) intimately involved with the microprocessor side of the house for way too damn long, I can tell you that when it came to microprocessors, Sun was all vision and no execution. The theme that was repeated over several microprocessors: a new, big idea that made all of the DEs horny, but that proved annoyingly tricky to implement. Sacrifices would then be made elsewhere in order to make a tape out date and/or power or die budget. But these sacrifices would be made without a real understanding of the consequences -- and the chip would arrive severely compromised. (Or wouldn't arrive at all.) Examples abound but include Viking, Cheetah, UltraJava/NanoJava/PicoJava, MAJC, Millennium (cancelled), Niagara (shared FPU!) and ROC (originally "Regatta-on-a-chip", but became "Rock" only when it was clear that it was going to be so late that it wasn't going to be meaningfully competing with IBM's Regatta after all). The only microprocessor that Sun really got unequivocally right (on time, on budget, leading performance, basically worked) was Spitfire -- but even then, on the subsequent shrinks (Blackbird and beyond) the grievous e-cache design flaws basically killed it. Point is: in microprocessors, execution isn't everything -- it's the only thing.

al2o3cr 13y ago

Verilog or GTFO.

panduwana 13y ago

If the belt operation can be changed from the current "take any two items on belt, process them, put the result to the front of belt" to "take two front-most items on belt, process them, put the result anywhere on belt", we can save some bits and make shorter instructions (good for mobile): currently: OP load-address-1 load-address-2 // output is always put at belt's front to: OP store-address // inputs are always 2 frontmost items on belt

willvarfar 13y ago
(See The Belt talk for an explanation of belt vs stack)
axman6 13y ago
How do you get ILP from this? Seems like it would make scheduling much more difficult because you now need to make sure that that the results you need for each instruction are in the order in the belt you need, and you have to be able to execute any order of instruction types. The mill can run fast partly because and instruction can use any result on the belt, and similar instructions are grouped together making decode simpler (from memory, they have two separate decoders and each instruction has all say arith instructions grouped and decoded by one decode, and all the others decoded by the other). Basically, I don't see how you can use what you suggest to do, in one instruction: [ add positions 7 and 5 | multiply positions 7 and 2 | call f on 4 and 5 | branch to foo if position 3 was LT else bar ] ending up with the belt [ [7]+[5], [7]*[2], f([4],[5]) ... ] or whatever you like. All you need to do to schedule the mill is to perform as many operations in parallel as the hardware can do, and then find out where their results would be placed to create the next instruction.
- panduwana 13y ago
  In the linked article it is said that "According to prior research, only some 13% of values are used more than once". So based on the research on which Mill is based on, your example and that "instruction can use any result on the belt" is actually minority case. As for scheduling my proposed store-addressed belt: you perform as many operations in parallel, then for each operation find the other operation that depends on the former's operation result, calculate the distance between them and assign it as the former's store address. The compiler has more work to do yes, but not "much more difficult".

vietor 13y ago

It's easy* to build a dramatically better performing and more efficient CPU than currently available if you don't have to restrict yourself to the code and compilers currently available. The exciting thing to me is that between wider availability of open source compilers and code, and a larger amount of user level code being written in interpreted languages (so only the language runtime needs to be rebuilt), there might actually be a future in alternative architectures. * As these things go...

nly 13y ago

My biggest concern is Intel will just buy and bury it.

DiabloD3 13y ago
OOB is unlikely to ever sell.

JoeAltmaier 13y ago

How is this different from a convention register model, where the compiler stores each result into a new register round-robin? That would be a belt too.

axman6 13y ago
That works fine until you have things like branches and function calls. Most call conventions specify which registers arguments are in, and with what you're proposing each function call needs to know where it is up to in the rotation at the beginning of the call. If the ahrdware looks after it (either through a index register that stores the position of the next write), then it becomes easier; but no one's doing that, and afaik, the mill is the first machine to do anything close. Stack machines are sort of similar, but word differently because they need to remember all values on the stack untill they're popped. The mill just forgets old results and the compiler must make sure they're still available when they're needed later.

klausnrooster 13y ago

Soon with Memristor RAM/SSD!