Live data from Hacker News

Introduction to the Mill CPU Programming Model

ootbcomp.com

11–20 of 81 posts

Re: Introduction to the Mill CPU Programming Model

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

Re: Introduction to the Mill CPU Programming Model

#12
post #6
post #5

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.

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.

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.

Re: Introduction to the Mill CPU Programming Model

#13

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

Re: Introduction to the Mill CPU Programming Model

#16
post #6

Earlier quoted context omitted.

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.

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…

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.

Ahhh. When I think of magic I think of stuff like optimizer heuristics that give incredible performance with very carefully written micro-benchmarks and abysmal performance in the worst case.

Re: Introduction to the Mill CPU Programming Model

#17
post #13

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

I am pretty sure this means 33 ops/cycle, as the question asked how far multi-pipeline model can be pushed.

Re: Introduction to the Mill CPU Programming Model

#18
post #13

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

Well, that probably is actually a new world record.
Post reply on HN