Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to the Mill CPU Programming Model

ootbcomp.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#71

Post by JoeAltmaier »

willvarfar wrote: post #35
JoeAltmaier wrote: post #32

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 (128b…

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.

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.

Re: Introduction to the Mill CPU Programming Model

#72

Post by zanny »

jmz92 wrote: post #27
outside1234 wrote: post #14

Earlier quoted context omitted.

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

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…

Back when Itanium hit the market we didn't have LLVM, I wonder how hard it would be to write an assembler for Mill with it.

Re: Introduction to the Mill CPU Programming Model

#73

Post by jmz92 »

zanny wrote: post #72
jmz92 wrote: post #27

Earlier quoted context omitted.

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…

Back when Itanium hit the market we didn't have LLVM, I wonder how hard it would be to write an assembler for Mill with it.

LLVM intermediate representation and Mill code are going to be pretty different. The LLVM machine model is a register based machine (with an arbitrary number of registers--the backends do the work of register allocation). Basically, an easier RISC-ish assembly.

So, while LLVM would be helpful for porting things to the Mill, as it's largely a "solve once use everywhere" problem, it's still not trivial. It could take a lot of effort to make it competitive.

Re: Introduction to the Mill CPU Programming Model

#74

Post by petermonsson »

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?

Re: Introduction to the Mill CPU Programming Model

#76

Post by willvarfar »

petermonsson wrote: post #74

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?

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.

Re: Introduction to the Mill CPU Programming Model

#77

Post by kazagistar »

al2o3cr wrote: post #42
solarexplorer wrote: post #15

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

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... ;)

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.

Re: Introduction to the Mill CPU Programming Model

#78

Post by thesz »

willvarfar wrote: post #8
TrainedMonkey wrote: post #4

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…

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…

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?

Re: Introduction to the Mill CPU Programming Model

#79

Post by petermonsson »

willvarfar wrote: post #76
petermonsson wrote: post #74

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?

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.

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

Re: Introduction to the Mill CPU Programming Model

#80

Post by Guvante »

jtuente wrote: post #24
Guvante wrote: post #23

Earlier quoted context omitted.

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 performanc…

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

But I bet if we compared core sizes that distinction would disappear, a CUDA core is incredibly compact after all.
Post reply on HN