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

21–30 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#21

Post by msandford »

chongli wrote: post #16
msandford wrote: post #12

Earlier quoted context omitted.

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

Yeah that makes perfect sense. I would probably refer to that as "cheating" rather than "magic" but I totally get the nomenclature mix-up.

Re: Introduction to the Mill CPU Programming Model

#23

Post by Guvante »

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.

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.

Re: Introduction to the Mill CPU Programming Model

#24

Post by jtuente »

Guvante wrote: post #23
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.

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.

Re: Introduction to the Mill CPU Programming Model

#25

Post by pbsd »

Guvante wrote: post #23
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.

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…

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.

Re: Introduction to the Mill CPU Programming Model

#26

Post by solarexplorer »

Guvante wrote: post #23
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.

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…

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.

Re: Introduction to the Mill CPU Programming Model

#27

Post by jmz92 »

outside1234 wrote: post #14
cpr wrote: post #10

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

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

Re: Introduction to the Mill CPU Programming Model

#28

Post by jmz92 »

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.

Re: Introduction to the Mill CPU Programming Model

#29

Post by fleitz »

willvarfar wrote: post #9
fleitz wrote: 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…

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.

Re: Introduction to the Mill CPU Programming Model

#30

Post by infogulch »

pbsd wrote: post #25
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…

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.

The mill's 33 ops/cycle are all independent operations, i.e. not counting individual vector elements.
Post reply on HN