Introduction to the Mill CPU Programming Model

http://ootbcomp.com/topic/introduction-to-the-mill-cpu-programming-model-2/

by luu • 12 years ago

208 79 12 years ago

DiabloD3• 12 years ago

I can't wait until designs like this become common.

Interesting, the architecture looks greatly simplified compared to even standard RISC (As opposed to lets say x86). Due to that simplification it will be power efficient while being inherently highly parallel.

Would be interesting to find out:

1. How high that degree of parallelism can be pushed, are we talking about tens or hundreds of pipelines?

2. What frequency this will operate at?

3. What is up with RAM? I saw nothing about memory, with lots of pipelines it is bound to be memory bound.

panic• 12 years ago

3. What is up with RAM? I saw nothing about memory, with lots of pipelines it is bound to be memory bound.

There's more information about memory in the talk at http://ootbcomp.com/topic/memory/

willvarfar10• 12 years ago

Hi, I'm the author of that intro. The talks which Ivan has been giving - there are links in that intro - go into everything in much more detail. But here's a quick overview of your specific questions:

1: we manage to issue 33 operations / sec. This is easily a world record :) The way we do this is covered in the Instruction Encoding talk. We could conceivably push it further, but its diminishing returns. We can have lots of cores too.

2: its process agnostic; the dial goes all the way up to 11

3: the on-chip cache is much quicker than conventional architectures as the TLB is not on the critical path and we typically have ~25% fewer reads on general purpose code due to backless memory and implicit zero. The main memory is conventional memory, though; if your algorithm is zig zagging unpredictably through main memory we can't magic that away

sp3322• 12 years ago

33 ops/sec? :)

cpleppert• 12 years ago

>: the on-chip cache is much quicker than conventional architectures as the TLB is not on the critical path

I would really like to know your reasoning that the TLB is a major bottleneck in conventional CPUs. CPUs execute a TLB lookup in parallel with the cache, so there is usually no latency except on a TLB miss.

Basic research on in-memory databases suggest eliminating the TLB would improve performance only by about 10%, this certainly isn't a realistic use case and most of the benefits can be obtained simply by using larger pages. So I don't really know where your claims about 25% fewer reads is coming from in relation to simply getting rid of virtual memory.

mtrimpe• 12 years ago

After the watching first Mill video I remember reading someone who said that this seemed like the perfect architecture for a lisp.

It was something about scopes mapping very well onto the Mill's "memory model."

I'm not quite up to that sort of analysis though, but I'm wondering if you see that too? If so, I would love to read more about that.

thesz• 12 years ago

33 operations/cycle require memory with (at least) 66 ports: 33 for reads and 33 for writes. Otherwise it is NOOP. For two-operand instructions the count goes to 99=33*3 and for three operand instructions (ternary operator) it goes to 132 ports.

As far as I know, Elbrus 3M managed to achieve about 18 instructions per clock cycle, with VLIW and highly complex register file, whose design slowed overall clock frequency to about 300MHz on 0.9um process. To get everything in comparison, plain Leon2 managed to get about 450MHz in the same process, without any tweaks and hand work and Leon2 is not a speed champion.

So the questions is: do you have your world record in simulation or in real hardware like FPGA?

jmz923• 12 years ago

"Interesting, the architecture looks greatly simplified compared to even standard RISC"

Depends on how you define simplicity, really. Writing a good back-end for this architecture is likely to be very challenging.

nanofortnight• 12 years ago

Not really. The temporal addressing is quite simple for a compiler to generate. Plus, Mill was designed by a compiler writer in the first place.

What challenges would you think a back-end developer would face?

fleitz3• 12 years ago

Great idea, since it's all theoretical currently I'm wondering with the compiler offloading how well it will actually perform. Itanium was capable of doing some amazing things, but the compiler tech never quite worked out.

chongli2• 12 years ago

The beauty of the Mill is that it's been designed from the start to make the compiler extremely simple and straightforward. There is no "magic" in the software here, it's all in the hardware.

msandford2• 12 years ago

Actually there's a fair bit of magic in the software as a result of exposing the hardware rather than trying to hide it. Once the software can know how long things will take, suddenly it can do things that in x86 land would be magical.

This seems to me philosophically what Sony was trying to do with the Cell processor. Expose the hardware to programmers so that they can manage things better. The big difference being that the Mill was designed by a compiler writer rather than a bunch of guys who design GPU pipelines.

willvarfar10• 12 years ago

Ah, but the Mill was primarily designed by a compiler writer ;)

Here's Ivan's bio that is tagged on his talks:

"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."

So actually its been designed almost compiler-first :)

fleitz3• 12 years ago

Still interested in how it works in practice. I'm pretty sure the Itanium team combined with Intel's compiler team have similar credentials.

I'm not saying it can't work, not saying it won't work, but we know that most code pointer chases. While CPU and compiler design is above my paygrade I know that often a lot of fancy CPU/design and compiler tricks that make things twice as fast on some benchmark leads to 2 to 3% performance gains on pointer chasing code.

Not sure how the Mill is going to make my ruby webapp go 8 times as fast by issuing 33 instructions instead of 4.

cpr• 12 years ago

Does anyone know how this compares with VLIW designs like the original Yale/Multiflow machines? Seems very familiar.

(I ask as a survivor of Multiflow in the late 80's. ;-)

outside1234• 12 years ago

Or more recently, how does this compare to the Itanic from Intel?

jmz923• 12 years ago

Some of the memory ideas are similar--Itanium had some good ideas about "hoisting" loads [1] which I think are more flexible than the Mill's solution. In general, this is a larger departure from existing architectures than Itanium was. Comparing it with Itanium, I doubt it will be successful in the marketplace for these reasons:

-Nobody could write a competitive compiler for Itanium, in large part because it was just different (VLIW-style scheduling is hard). The Mill is stranger still. -Itanium failed to get a foothold despite a huge marketing effort from the biggest player in the field. -Right now, everybody's needs are being met by the combination of x86 and ARM (with some POWER, MIPS, and SPARC on the fringes). These are doing well enough right now that very few people are going to want to go through the work to port to a wildly new architecture.

[1] http://en.wikipedia.org/wiki/Advanced_load_address_table

solarexplorer3• 12 years ago

It sure does look like a Multiflow on steroids...

auvrw• 12 years ago

as someone who knows next to nothing about cpu architecture but has watched most of the videos, it seems as though all the concepts are broadly familiar ones to experienced architecture people, but the details of every corner are slightly rearranged.

the position of the translation lookahead buffer is one example of this. that portion of the memory talk goes something like

Ivan: usually the TLB is located here [points to slide]. in the mill it's here [flips to next slide].

Audience: gasp!

Symmetry4• 12 years ago

Well, this seems to fall within the VLIW tradition and has an exposed pipeline like the original VLIW, but there are a bunch of differences. In the original VLIW every instruction pipeline was conceptually a different processor while the Mill is very much unified around it's single belt, though I wonder if you could have a similar design with separate integer and floating point belts.

And instead of having a fixed instruction format the Mill has variable length bundles, which is good. Instruction cache pressure is certainly a traditional weakness of VLIW. So maybe you could say Mill:VLIW::CISC:RISC? But the most important part of RISC was separating memory access from operations and the Mill still certainly does that.

Mjolnir2• 12 years ago

Very very interesting, thanks for sharing! What would the path be to using existing code/where would Mill appear logically first?

Also, could something like Mill work well within the HSA/Fusion/hybrid GPGPU paradigm? E.g. from my very amateur reading of your documents, it looks like a much needed and very substantial improvement to single threaded code; how would a mixed case where we have heavy matrix multiplication in some parts of our code as part of a pipeline with sequential dependencies work? Would an ideal case be a cluster (or some fast interconnect fabric in a multi socket system) of multi core Mill chips be the future?

Realistically, is this something that LLVM could relatively easily target? A simple add in card that could give something like Julia an order of magnitude improvement would be a very interesting proposition, especially in the HPC market. I come at this mainly from an interest how this will benefit compute intense machine learning/AI applications.

Sorry for all the questions.

rcxdude3• 12 years ago

The latest talk on their website mentions the LLVM status in passing at the end. Essentially they're moving their internal compiler over to use LLVM, but it requires fixing/removing some assumptions in LLVM because the architecture is so different, and the porting effort was interrupted by their emergence from stealth mode to file patents.

Mjolnir2• 12 years ago

Thanks, I'll have a look at the talks.

solarexplorer3• 12 years ago

The Mill has a 10x single-thread power/performance gain over conventional out-of-order (OoO) superscalar architectures

It would be nice to know how they got that number. Because it seems to be too good to be true.

Guvante2• 12 years ago

I am pretty sure they are talking about per-cycle performance. Since they can do 33 operations per cycle. IIRC the peak performance of an Intel chip at the moment is 6 FLOP per 2 cycles (or there abouts).

Of course this is beyond ridiculous since a 780 TI can pull off 5 TFLOP/sec on a little under a GHz clock, 5,000 FLOP per cycle is a little more than 33.

It seems like an interesting design, but comparing performance against what an x64 chip can do is a bit silly, you can't just pick numbers at random and call that the overall improvement.

jtuente• 12 years ago

5,000 FLOP per cycle using 2,880 CUDA cores, so less than 2 FLOP/cycle/core.

pbsd2• 12 years ago

A Haswell core can do 2 vector multiply-adds per cycle, which results in a peak of 32 single-precision FLOP per cycle per core or 16 double-precision FLOP per cycle per core.

solarexplorer3• 12 years ago

Well, at least they should tell _which_ number they picked. They also mention power, so I would expect it's something more than just instructions per cycle.

rcxdude3• 12 years ago

I think their first to third talks go into more detail on this. IIRC it's something like ops per second per watt (and not completely theoretical best-case either: based on running realistic code in sim).

al2o3cr• 12 years ago

Given that there's not a publicly-available simulator or compiler for the Mill, I hope they washed their hands after retrieving those figures. The GI tract is not a friendly place... ;)

kazagistar• 12 years ago

They have been running simulations and had working compilers for a while now. We cannot verify the numbers yet, but they don't seem to just be pulled out of thin air.

sehugg• 12 years ago

For those that are mainly software-oriented, the Lighterra overview posted earlier is helpful background for understanding where VLIW fits into the zoo of CPU architectures:

http://www.lighterra.com/papers/modernmicroprocessors/

adamnemecek• 12 years ago

This might be one of the most interesting things posted on HN.

JoeAltmaier2• 12 years ago

Some kinds of code will benefit from this - long calculations and deep nested procedures. But lots of hangups on consumer applications are in synchronization, kernel calls, copying and event handling.

I'd like to see an architecture address those somehow. E.g. virtualize hardware devices instead of writing kernel-mode drivers. Create instructions to synchronize hyperthreads instead of kernel calls (e.g. a large (128bit?) event register, a stall-on-event opcode). If interrupts were events then a thread could wait on an interrupt without entering the kernel.

willvarfar10• 12 years ago

Actually, the Mill is designed to address this; it has TLS segment for cheap green threading, SAS for cheap syscall and microkernel arch, cheap calls and several details for IPC which are not public yet.

JoeAltmaier2• 12 years ago

What about synchronization? Folks are terrified of threads because synchronizing is so hard. But a thread model can be the simplest especially in message models.

the_mitsuhiko• 12 years ago

I still want to know how to implement fork for it.

kristianp• 12 years ago

There is some discussion of fork here:

https://groups.google.com/forum/#!topic/comp.arch/sICkAag4ga...

chmike• 12 years ago

I'm skeptic of the belt efficiency. Memory storage will be wasted. What do we gain with it ?

Rusky• 12 years ago

From what I understand it would have very similar characteristics to current register renaming. You just get direct access to the whole register file rather than just a few ISA registers.

I think it would require some instruction scheduling to make optimal use of it, but that means the silicon doesn't need that logic so cores can be smaller and more efficient.

cordite• 12 years ago

How well could LLVM be converted to the mill intermediate language?

willvarfar10• 12 years ago

We are starting work on an LLVM back end now. The tool chain will be described in an upcoming talk, so subscribe to the mailing list if you want to be in the audience or watch any available live streams.

I am also going to make a doc or presentation called "A Sufficiently Smart Compiler" to explain how easily the Mill can vectorise your normal code and so on :)

karavelov2• 12 years ago

In my regards it seems that one of their sources of inspiration were Transmeta processors - VLIW core, software translator from some intermediate bytecode (x86 in case of transmeta). I hope they will get it better this time.

jlouis2• 12 years ago

They don't translate. Rather, they compile code to their instruction set.

karavelov2• 12 years ago

yes, wrong wording on my part

Symmetry4• 12 years ago

Well, the plan is to distribute an intermediate representation and then specialize it to the particular mill pipeline the first time you load the binary. Probably a lot easier than translating something that wasn't designed for it.

snorkel• 12 years ago

Very interesting reading. Are such procs already being sold or is this still on the workbench?

szatkus• 12 years ago

No, it will available in few years :(

Symmetry4• 12 years ago

This whole thing is just horribly exciting for a computer architecture geek like me. I am somewhat worried about the software side given the number of OS changes that would have to be made to support this. But then again, there are lots of places in the world where people are running simple RTOSes on high end chips and the Mill probably has a good chance there. The initial plan to use an older process and automated design means that the Mill can probably be profitable in relatively modest volumes.

petermonsson2• 12 years ago

There is something that I can't get to add up here. The phasing claims that there are only 3 pipeline stages compared to 5 in the textbook RISC architecture or 14-16 in a conventional Intel processor, but this can't possibly add up with the 4 cycle division or the 5 cycle mis-predict penalty.

What am I getting wrong?

willvarfar10• 12 years ago

The phase says when the op issues. It takes some number of cycles before it retires. So an divide issues in the "op phase" in the second cycle, and if on the particular Mill model it takes 4 cycles then it retires on the fifth.

If there is a mispredict, there is a stall while the correct instruction is fetched from the instruction L1 cache. If you are unlucky, it's not there and you need to wait longer.

petermonsson2• 12 years ago

OK, so the phases aren't an apples to apples comparison to the traditional pipeline stage, but more in line with the TI C6x fetch, decode, execute pipeline which for TI covers something like 4 fetch stages, 2 decode stages and between 1and 5 execute stages. Thank you for the clarification

Introduction to the Mill CPU Programming Model

Related Stories