Live data from Hacker News

Introduction to the Mill CPU Programming Model

ootbcomp.com

1–10 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#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 nothing about memory, with lots of pipelines it is bound to be memory bound.

Re: Introduction to the Mill CPU Programming Model

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

Re: Introduction to the Mill CPU Programming Model

#7

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…

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/

Re: Introduction to the Mill CPU Programming Model

#8

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

Re: Introduction to the Mill CPU Programming Model

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

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

Post reply on HN