▲ 274 points
back
94 comments
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.
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.
Not quite: only scheduling and binary creation is done at install time. Instruction selection and optimization is done during compilation in the usual way.
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.
#1) Mill cache is relatively conventional (except with 9-bit bytes). Everybody uses the EDA tools to create caches, so everybody will get similar power numbers. However, there's a lot more to the hierarchy power budget than the caches: read buffers, write buffers, pin drivers, etc. The Mill has neither read nor write buffering, and backless lines don't drive pins. We won't have good numbers until we have gate-level sims of the hierarchy, so for now all there is to go on is skill and expertise. We're not worried; YMMV.
#2) The bypass is similar for the FU-to-FU paths, but an OOO has to also feed from the renames that the Mill doesn't have.
#3) The OS port is a largely solved problem: we expect to use the L4 microkernel as a base and the existing L4-based Linux etc. implementations on that. https://en.wikipedia.org/wiki/L4_microkernel_family. Porting L4 to the Mill is pretty easy; we designed it that way :-)
As I understand it, Mill has no privilege mode so I don't see why you need even L4! Providing a Unix compatible API (all except fork()) is basically just building a modular emulator. Mostly grunge work once you work out the access rights matrix :-)
How far along are you on the OS work? Have you booted anything on the simulators?
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.)
Assuming their translation step is as cheap as they claim (single pass rewrite/substitute missing hardware for software macros), it's conceivable that there isn't much value in persistently caching the result.
In that case, everything could be contained to a single ld.so patch, or (doubtfully) a modification to the kernel ELF loader
Finally, and although it is less common now, in prior days Linux already had a post-install processing step for binaries on certain distributions - prelink(8) ( https://en.wikipedia.org/wiki/Prelink )
Sounds like Java and .Net Bytecode. I don't deal with Java much, but in .Net world IL is jitted on demand into memory and thrown away when the process is recycled unless you do ngen, which is difficult to do in many situations (web applications).
I think many underestimate the overhead involved in compiling IL to native including MS themselves. There are user perceivable delays in application startup time in larger code bases that lead to a worse user experience. Why they don't cache jitted code to disk after 5-6 version of .Net is beyond me, even Mono has a AOT compiler.
I am starting to appreciate the AOT approach of "native" code (C,C++,GO), do as much as possible one time, at compile time. Don't make the user wait because you want to distribute a single portable binary.
I sort of assumed that they would just use fat binaries, and store the cached, translated version in the same file as the intermediate code.
I would like it very much if alternative to '70s era operating systems were to flourish on newer hardware platforms. If Mill hardware backs up the performance claims, it would open an interesting door that's been shut to non Multics-likes for too long.
>>All of which is to say, I think the 10x they're talking about is unrealistic.
I think that is putting it mildly and is a little strange to somehow claim in the first place. That can't possibly be true, their isn't room for a 10X increase in optimization on an Intel core chip and would be impossible to reach based on memory bandwidth and the amount of execution resources available on a chip alone. The ideas they have concretely put forth simply don't work or don't really provide a performance increase.
Take their virtual memoryless implementation. Getting rid of virtual memory doesn't buy you a whole lot especially when you need to add in a protection mechanism that looks a lot like a TLB in the first place(and must have the same general properties to provide protection, you just gain very marginal lookup costs).
If you do the math, this can't add more than 1-2% in performance in common application software at the cost of making every modern operating system unusable and increasing memory consumption(embedded systems anyone?). If getting rid of virtual memory was so great, why didn't someone do it in every other preceding clean room architecture? My answer: It isn't.
Or consider how they want to do branch prediction: add a separate ISA to do static branch prediction that is added by the compiler and loaded asynchronously by another cpu component and then supplied to the main cpu.
First of all, this doesn't work. The CPU can't have performance critical data pushed to it by another component. There is a reason the Branch prediction table and branch target buffers are small and focused and able to be accessed quickly. Secondly, static branch prediction is awful. You simply must be able to modify branch prediction data as the CPU executes to provide optimum performance. So it seems they want to be more power hungry, more complex, and have less performance than a mainstream CPU when it comes to branch prediction.
It is possible I have misinterpreted some elements of this scheme but basic design decisions like putting branch prediction into a separate component of the CPU simple don't make sense at all from a chip layout perspective.
Finally, I'm not really sure where the performance is supposed to come from with the 'belt' in the first place. Data dependency is incredibly complex in a modern pipelined cpu and while it is possible to reduce the cost by precompiling software for an optimized CPU the benefits are all very low level and really don't extend beyond reduced power consumption(assuming compilation cost can be amortized). At some point, to get more instruction level parallelism you simply have to bite the bullet and do dynamic out of order scheduling in the CPU to extract more performance. This has a well defined cost and an upper level limitation on how much total parallelism a CPU can extract from an instruction stream. Think of it another way: a static compiler has less information than a running CPU so one can't expect it to be able to extract more parallelism than the CPU itself.
The Instruction Encoding talk http://millcomputing.com/topic/instruction-encoding/ was the first talk, so explained these numbers in the first few slides.
DSPs are massively faster than your Out-of-order Superscalar Monster, just ... not on general purpose code.
The Mill is a DSP-like architecture with secret sauce so it can overcome the gotchas and go DSP-fast on general purpose code.
>>All of which is to say, I think the 10x they're talking about is unrealistic.
Bear in mind they are claiming 10x improvement in MIPS/Watt, not MIPS. So I guess what they are aiming at is a 13W chip with i7 performance.
Even if they managed a 65W i7 they would be on a winner.
> The differences between how they and LLVM handle pointer is causing them trouble
Could you please elaborate? What is the difference in the way the Mill and LLVM handle pointers?
Ivan has said the problem is that the LLVM treats all pointers as integers.
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.
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.
ROC (originally "Regatta-on-a-chip")
Really? Ha, that is funny! I guess sun got the codenames and the fact that it was MCM full of GP's, but apparently didn't notice why it was MCM, or the fact that there were 4 MCM's in the full regatta config.
I mean, like, did sun expect to make a wafer level chip?
Its good to know the envy went both directions, I remember a lot of talk about sun's E10k...
Hi Brian.
Spitfire was only on-time compared to the debacle of Viking and Voyager.
Thanks for dredging up the nightmare. :-)
>>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.
This is a detailed description of the architecture: 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.
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"
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.
> Ivan Godard has designed, implemented or led the teams for 11 compilers for a variety of languages and targets, an operating system, an object-oriented database, and four instruction set architectures. He participated in the revision of Algol68 and is mentioned in its Report, was on the Green team that won the Ada language competition, designed the Mary family of system implementation languages, and was founding editor of the Machine Oriented Languages Bulletin. He is a Member Emeritus of IFIPS Working Group 2.4 (Implementation languages) and was a member of the committee that produced the IEEE and ISO floating-point standard 754-2011.
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...
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.
(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.
Will you contribute it to upstream, or keep it closed source?
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.
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-se...
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...
What differentiates Mill with Itanium?
Also, what are the 2.3x power/performance improvements based on? Is there silicon for this?
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/
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.
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.
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.
Any pointers to write ups about this?
I want to replace every computer in the world with this.
My biggest concern is Intel will just buy and bury it.
OOB is unlikely to ever sell.
Can't wait to buy a Mill and mess around with it. Hopefully it isn't more expensive than current desktop or server processors.
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.
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.
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
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 ]
[ [7]+[5], [7]*[2], f([4],[5]) ... ]
(See The Belt talk for an explanation of belt vs stack)
Verilog or GTFO.
Soon with Memristor RAM/SSD!