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

51–60 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#51

Post by jacobolus »

cpleppert wrote: post #45
willvarfar wrote: post #8

Earlier quoted context omitted.

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…

>>: 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 abou…

Have you watched Godard’s talks? He goes into considerable detail about this.

Re: Introduction to the Mill CPU Programming Model

#52

Post by Rusky »

chmike wrote: post #50

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

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.

Re: Introduction to the Mill CPU Programming Model

#54

Post by nanofortnight »

jmz92 wrote: post #28
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…

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

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?

Re: Introduction to the Mill CPU Programming Model

#55

Post by willvarfar »

cordite wrote: post #53

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

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 :)

Re: Introduction to the Mill CPU Programming Model

#56

Post by willvarfar »

sp332 wrote: post #13
willvarfar wrote: post #8

Earlier quoted context omitted.

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 ops/sec? :)

Oooh, too late for me to correct that particular typo :)

33 ops / cycle, sustained. Last night we also published an example list of the FU mix on those pipelines here: http://ootbcomp.com/topic/introduction-to-the-mill-cpu-progr...

Re: Introduction to the Mill CPU Programming Model

#57

Post by willvarfar »

fleitz wrote: post #29
willvarfar wrote: post #9

Earlier quoted context omitted.

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…

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

The speedup for Ruby will come from the Mill enabling faster DBs and services for you to use, and from Ruby VM improvements that are not perhaps Mill -specific.

If you pick Ruby as your platform, though, you are really picking a point on the runtime vs developing speed tradeoff that perhaps suggests you plan to scale sideways rather than upwards anyway; in which case the hosting platform for your app may be interested in Mill even if its users are ambivient.

Pointer chasing is a major concern, and the Mill can't magic it away. But there are other parts of your Ruby webapp that are a big deal such as event loops, continuations and garbage collection, where again the Mill has special sauce. There is also special attention paid to syscall performance on the Mill. Rails has a staggering number of syscalls per request, and django to pick an alternative has very few, so I'd still hope Rails moderates syscalls a bit.

Re: Introduction to the Mill CPU Programming Model

#58

Post by willvarfar »

pbsd wrote: post #43
willvarfar wrote: post #39

Earlier quoted context omitted.

The instruction encoding talk starts with comparison between Mill, DSP and Haswell and tries to explain the basic math. The Mill is a DSP that can run normal, "general purpose" code better - 10x better - than an OoO superscalar. The Mill used in the comparison - one for your laptop - is able to issue 8 SIMD integer ops and 2 SIMD FP ops each cycle, plus other logic.

I was strictly replying to the Intel FLOPs claim of the parent comment. I have only a faint idea how the Mill CPU works, so I can't really compare against it. From the little I have read, the Mill CPU looks like a cool idea, but I'm skeptical about the claims. I'd rather see claims of efficiency on particular kernels (this can be cherry-picked too, but at least it will be useful to somebody ) than pure instruction de…

Apologies, I was replying to the thread in general and not your post in particular.

Art has now published the 33 pipeline breakdown on the "Gold" Mill here: http://ootbcomp.com/topic/introduction-to-the-mill-cpu-progr...

A key thing generally is that vectorisation on the Mill is applicable to almost all while loops, so is about speeding up normal code (which is 80% loops with conditions and flow of control) as well as classic math.

Re: Introduction to the Mill CPU Programming Model

#59

Post by mtrimpe »

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…

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.

Re: Introduction to the Mill CPU Programming Model

#60

Post by sp332 »

fleitz wrote: post #49
haberman wrote: post #40

Earlier quoted context omitted.

> Not sure how the Mill is going to make my ruby webapp go 8 times as fast by issuing 33 instructions instead of 4. 8x speed is not being claimed, 10x power/performance is. That could mean that the app runs at the same speed but the CPU uses 10% of the power. A lot of the power saving probably comes from eliminating many part of modern CPUs like out-of-order circuitry.

Ok, so now that it's 10x power/performance I buy 10 of these things and it still only delivers 5% more webpages. This kind of mealymouthed microbenchmark crap is exactly what the industry doesn't need, if I have a bunch of code that is pure in order mul/div/add/sub then I put it on a GPU that I already have and it goes gangbusters. The problem is most code chases pointers. Like I said, great idea, would love to see s…

I never thought of serving webpages as being CPU-bound. Anyway, to get a 10x speedup, you would have to buy enough of these to use as much power as whatever you're replacing. So if one Mill CPU uses 2% as much power as a Haswell, then you'd have to buy 50 of them to see a 10x performance improvement over the Haswell.
Post reply on HN