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

41–50 of 81 posts

Re: Introduction to the Mill CPU Programming Model

#41

Post by jitl »

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). 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.
That's not true at all. The biggest high-performance compute is being done on special parallel architectures from Nvidia [1] (Tesla). Intel trying to bring X86 back into the race with its Xeon Phi co-processer boards [2].

[1] http://www.top500.org/lists/2013/11/

[2] http://www.intel.com/content/www/us/en/processors/xeon/xeon-...

Re: Introduction to the Mill CPU Programming Model

#42

Post by al2o3cr »

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.

Given that there's not a publicly-available simulator or compiler for the Mill, I hope they washed their hands after retrieving those figures. The GI tract is not a friendly place... ;)

Re: Introduction to the Mill CPU Programming Model

#43

Post by pbsd »

willvarfar wrote: post #39
pbsd wrote: post #25

Earlier quoted context omitted.

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.

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 decoding/issuing numbers. Those are like peak FLOPs: depending on the rest of the architecture they can become effectively impossible to achieve in reality. In any case, I'm looking forward to hearing more about this.

Re: Introduction to the Mill CPU Programming Model

#45

Post by cpleppert »

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…

>>: 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 about 10%, this certainly isn't a realistic use case and most of the benefits can be obtained simply by using larger pages. So I don't really know where your claims about 25% fewer reads is coming from in relation to simply getting rid of virtual memory.

Re: Introduction to the Mill CPU Programming Model

#46

Post by Mjolnir »

rcxdude wrote: post #34
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.

Thanks, I'll have a look at the talks.

Re: Introduction to the Mill CPU Programming Model

#47

Post by ww520 »

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

Probably 33 operations in parallel since the original question was talking about parallelism.

Re: Introduction to the Mill CPU Programming Model

#48

Post by Scaevolus »

jitl wrote: post #41
jmz92 wrote: post #27

Earlier quoted context omitted.

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). 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. That's not true at all. The biggest high-performance compute is being done on special parallel architectures from Nvidia [1] (Tesla). Intel try…

The Mill aims to be good at general purpose computation. HPC is not general purpose computation, and is a tiny fraction of the market.

Re: Introduction to the Mill CPU Programming Model

#49

Post by fleitz »

haberman wrote: post #40
fleitz wrote: post #29

Earlier quoted context omitted.

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.

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 something that can actually serve webpages 10x as fast or 1/10th the power (and cost similar to today's systems)

Post reply on HN