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

31–40 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#31

Post by auvrw »

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

as someone who knows next to nothing about cpu architecture but has watched most of the videos, it seems as though all the concepts are broadly familiar ones to experienced architecture people, but the details of every corner are slightly rearranged.

the position of the translation lookahead buffer is one example of this. that portion of the memory talk goes something like

Ivan: usually the TLB is located here [points to slide]. in the mill it's here [flips to next slide].

Audience: gasp!

Re: Introduction to the Mill CPU Programming Model

#32

Post by JoeAltmaier »

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 (128bit?) event register, a stall-on-event opcode). If interrupts were events then a thread could wait on an interrupt without entering the kernel.

Re: Introduction to the Mill CPU Programming Model

#33

Post by rcxdude »

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…

The compiler part seems to be a core part of the mill's strategy: the representation and design seems to be oriented towards making it easy to compile for (the guy who gives the talks is a compiler writer). If the performance gains are half as good as advertised, and porting is not a complete pain (and it seems it won't be too bad), then they will have little difficulty attracting market share, even if only in niche applications at first.

Re: Introduction to the Mill CPU Programming Model

#34

Post by rcxdude »

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

The latest talk on their website mentions the LLVM status in passing at the end. Essentially they're moving their internal compiler over to use LLVM, but it requires fixing/removing some assumptions in LLVM because the architecture is so different, and the porting effort was interrupted by their emergence from stealth mode to file patents.

Re: Introduction to the Mill CPU Programming Model

#35

Post by willvarfar »

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.

Re: Introduction to the Mill CPU Programming Model

#36

Post by rcxdude »

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 think their first to third talks go into more detail on this. IIRC it's something like ops per second per watt (and not completely theoretical best-case either: based on running realistic code in sim).

Re: Introduction to the Mill CPU Programming Model

#37

Post by leoc »

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…

> Right now, everybody's needs are being met by the combination of x86 and ARM (with some POWER, MIPS, and SPARC on the fringes).

I'm not sure. I think that a hard port to a new architecture must look a lot more like a worthwhile effort now that the wait-six-months Plan A no longer works, especially for single-threaded workloads. Provided the new architecture can actually deliver the goods, of course.

Re: Introduction to the Mill CPU Programming Model

#39

Post by willvarfar »

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

Re: Introduction to the Mill CPU Programming Model

#40

Post by haberman »

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

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

Post reply on HN