Intel and the big.LITTLE concept

[Exophase]

Intel will have the process advantage (as in they haven't really exercised it on Atom yet) and the process advantage helps power consumption more than it does switching performance. At least in theory. It also helps performance by giving more area, though (which is why tocks have room to grow over ticks, which don't tend to utilize much of the newly available die space)

But the improvements from the process advantages aren't as good as they used to be..

 

[Fjodor2001]

Intel will have the process advantage (as in they haven't really exercised it on Atom yet) and the process advantage helps power consumption more than it does switching performance. At least in theory. It also helps performance by giving more area, though (which is why tocks have room to grow over ticks, which don't tend to utilize much of the newly available die space)

But the improvements from the process advantages aren't as good as they used to be..

If it was only about process technology, Intel would have had better power consumption than ARM a long time ago. But the fact is that other factors come into play as well, such as different uarch. And such factors are the reason why ARM is so much more power efficient than Intel.

 

[tommo123]

Another question that should be raised: Do most people need more CPU performance in their mobile phones? Aren't we reaching a level where it is good enough for most people, i.e. same as for desktop CPUs?

I'd rather have better battery life than better CPU performance in my mobile phone. Remember the pre-Android and pre-iPhone days when you only had to charge your phone every two weeks? :thumbsup:

And assuming CPU performance is good enough and the focus instead is on battery life, doesn't it looks like ARM will win that battle after all?

nope. even the best phone out now can lag in some circumstances so no - it'snot good enough. it'll be like the old PC days. hardware gets faster - the OS and apps make more use of it which requires ever more powerful hardware

 

[podspi]

Yeah, smartphones definitely are not even close to 'good enough' at this point.

They ARE fast enough where the user experience is decent most of the time, but you do get lagging, you do get freeze-ups, and you do sit waiting for the phone a decent amount of the time.

 

[Fjodor2001]

Yeah, smartphones definitely are not even close to 'good enough' at this point.

They ARE fast enough where the user experience is decent most of the time, but you do get lagging, you do get freeze-ups, and you do sit waiting for the phone a decent amount of the time.

The question is why that occurs? Are you sure it's because of too low CPU performance? Can't it just as well be poorly designed OS & SW, I/O performance bottlenecks, and so on?

 

[ShintaiDK]

The question is why that occurs? Are you sure it's because of too low CPU performance? Can't it just as well be poorly designed OS & SW, I/O performance bottlenecks, and so on?

In utopia no. In real world yes.

Its too costly to optimize software and start from clean every time. Just look at browsers, you quickly use 50-250MB just to show a webpage. And the browsers basicly acts like mini OSes.

 

[Fjodor2001]

In utopia no. In real world yes.

Its too costly to optimize software and start from clean every time. Just look at browsers, you quickly use 50-250MB just to show a webpage. And the browsers basicly acts like mini OSes.

If the SW is making blocking calls while holding locks, waiting on timers or I/O operations and so on, then it may not help increasing the CPU performance.

Also, for another example see e.g. the improvements that were done on Android 4.1 under "Faster, Smoother, More Responsive" and "Vsync for apps" here:

http://developer.android.com/about/versions/jelly-bean.html

Without such SW changes, it may not be possible to get a smooth UI experience anyway, even if the CPU performance is increased.

 

[Fjodor2001]

Is there really any way for Intel to win the battle with ARM of the most power efficient CPU, if they both have access to the same processing technology?

As far as I know, the uArch that ARM use if much more power efficient than x86. So how can Intel then ever win that battle (unless it relies on having better chip process technology)?

 

[pelov]

Is there really any way for Intel to win the battle with ARM of the most power efficient CPU, if they both have access to the same processing technology?

As far as I know, the uArch that ARM use if much more power efficient than x86. So how can Intel then ever win that battle (unless it relies on having better chip process technology)?

It's not "much more power efficient" but yes, it is slightly more efficient. It doesn't get as big and bulky as does x86 due to the all the legacy ties. Comparatively, small ARM cores are very small whereas Atom cores are bigger.

You can't really compare something like the A15 to a Sandy Bridge cores as they're not anywhere close in size or performance, so a more fitting comparison would be Atom versus A15.

 

[Fjodor2001]

Comparatively, small ARM cores are very small whereas Atom cores are bigger.
[...]
You can't really compare something like the A15 to a Sandy Bridge cores as they're not anywhere close in size or performance, so a more fitting comparison would be Atom versus A15.

Soooo.... ARM uArch is more power efficient after all, right?

 

[pelov]

Soooo.... ARM uArch is more power efficient after all, right?

If Intel keeps making chips like they are, then yes. If Intel makes a very "slimmed down" x86 (which wouldn't really be x86), then no.

It's not that simple, though. There's the fab process, uArch IP, and software that make that an impossibility to compare with an "apples to apples" sort of way.

 

[AaronGolliver]

Intel couldn't even do this with Ivy Bridge and Atom as it currently stands.. For next generation it'll either need Silvermont Atoms with AVX2 support (currently they lack even SSE4) or castrated Haswell without AVX2... Intel has been releasing lower end CPUs without AVX since SB, but I hope they change their mind with Haswell. At any rate they've never been about relegating the best power consumption figures solely to their cheapest low end processors.

Intel actually did mix Xeon and Atom processors in the QuickIA system, and they wrote a custom linux kernel that would detect when an instruction set mis-match was detected (at run-time)

Here's a paper about it. (idk if you have to pay or not)

http://www.google.com/url?sa=t&rct=...BdPCtXmEqX5RrcRcA&sig2=QLgYNt25xR8lMe9lV3q1Zg

and a paper from Berkeley CS labs who used the QuickIA to do power-measurement / performance tests

http://cadlab.cs.ucla.edu/~cong/papers/islped12_y.pdf

 

[Exophase]

Intel actually did mix Xeon and Atom processors in the QuickIA system, and they wrote a custom linux kernel that would detect when an instruction set mis-match was detected (at run-time)

Here's a paper about it. (idk if you have to pay or not)

http://www.google.com/url?sa=t&rct=...BdPCtXmEqX5RrcRcA&sig2=QLgYNt25xR8lMe9lV3q1Zg

and a paper from Berkeley CS labs who used the QuickIA to do power-measurement / performance tests

http://cadlab.cs.ucla.edu/~cong/papers/islped12_y.pdf

Can't read the first paper, yes you do have to pay.

Nothing in the second one even acknowledges an ISA mismatch problem. They probably artificially limited the system to running programs with the minimal common ISA. That aside, I couldn't even find a reference to which Xeon they were using, so we don't even know what its instruction set is.

Maybe this wasn't clear from my post, I'll try to reiterate: you can't do this with Ivy Bridge and Atom unless you:

a) Don't allow threads that are incompatible with Atom from migrating to it, making it an incomplete system wrt what big.LITTLE is supposed to accomplish
b) Don't allow threads that are incompatible with Atom from running period, either by limiting the IB hardware to a lower instruction set or restricting it in software
c) Emulate the instructions you can't run, which can quickly become unacceptable from a software point of view, especially if you're missing entire register files like in the case of AVX. You could choose to peg these processes to the IB cores when it's determined there's a lot of emulation needed. The problem is that the newer instructions isn't indicative of low power requirements, when the instructions increase perf/W for getting that workload done...

No matter how you look at it, to offer what ARM is with big.LITTLE you must have the same ISA. Don't be misled by the paper when they refer to heterogeneous multicore, big.LITTLE is heterogeneous but the architecture support isn't.

 

[Khato]

It's not "much more power efficient" but yes, it is slightly more efficient. It doesn't get as big and bulky as does x86 due to the all the legacy ties. Comparatively, small ARM cores are very small whereas Atom cores are bigger.

You can't really compare something like the A15 to a Sandy Bridge cores as they're not anywhere close in size or performance, so a more fitting comparison would be Atom versus A15.

It's actually quite interesting to compare individual core sizes. While there's going to be some disparity between the different manufacturer's 32nm process node, it at least provides a reasonably valid comparison point.

Intel Medfield Core (512 kB of L2 cache) - rough estimate of 8.32 mm^2
Intel SNB Core (256 kB of L2 cache, not including L3) - 17.2 mm^2
Apple A6 Core (including 1/2 of the 1MB L2 cache) - 7.92 mm^2

Unfortunately I've not yet come across anything to really even hint at either Snapdragon S4 or ARM A15 core sizes. The comparison between Medfield and Apple's A6 is definitely interesting though given how they compare in performance. Then, of course, it's also interesting to observe that Intel's 'big' cores are only a bit over twice the size... and far more than that in both performance and power usage, haha.

 

[pelov]

It's actually quite interesting to compare individual core sizes. While there's going to be some disparity between the different manufacturer's 32nm process node, it at least provides a reasonably valid comparison point.

Intel Medfield Core (512 kB of L2 cache) - rough estimate of 8.32 mm^2
Intel SNB Core (256 kB of L2 cache, not including L3) - 17.2 mm^2
Apple A6 Core (including 1/2 of the 1MB L2 cache) - 7.92 mm^2

The Medfield is at a disadvantage simply being CISC. It has to have additional space for decoding the micro-ops from x86 CISC to RISC. Keep in mind that the Medfield core lacks modern x86-derived (FPU based) ISAs as well. If Intel implements a big.LITTLE approach then they'd need to have all the cores speaking the same language. An Atom core with AVX or AVX2 is a bigger Atom core.

The SNB core is quite beefy and wide. Does anyone know how big Haswell's cores will be?

 

[Khato]

The Medfield is at a disadvantage simply being CISC. It has to have additional space for decoding the micro-ops from x86 CISC to RISC. Keep in mind that the Medfield core lacks modern x86-derived (FPU based) ISAs as well. If Intel implements a big.LITTLE approach then they'd need to have all the cores speaking the same language. An Atom core with AVX or AVX2 is a bigger Atom core.

The SNB core is quite beefy and wide. Does anyone know how big Haswell's cores will be?

I believe that you are severely over-estimating the disadvantage that being 'CISC' results in. No question that tweaking the logic to be compliant with the complete instruction set would add a bit, but I doubt it'd be even a 5% area increase.

Regarding Core die sizes (including L2, but not L3), I believe these are approximately correct:

SNB - 17.2 mm^2
IVB - 13.2 mm^2
HSW - 12.9 mm^2

 

[pelov]

I believe that you are severely over-estimating the disadvantage that being 'CISC' results in. No question that tweaking the logic to be compliant with the complete instruction set would add a bit, but I doubt it'd be even a 5% area increase.

Regarding Core die sizes (including L2, but not L3), I believe these are approximately correct:

SNB - 17.2 mm^2
IVB - 13.2 mm^2
HSW - 12.9 mm^2

Bear in mind those figures are on a different node than SB. It's nice to see Haswell decreasing the size further on the same node, though. The fine tuning for 22nm helps

I'm not arguing that it's a substantial amount of die space, I'm just arguing that it's there. The leaner RISC architecture is always going to be a little slimmer just because it's RISC. What's going to take up more die space is the pipelines and the ISAs attributed to the FPU. Something like AVX2 in an Atom core will mean you've got a bigger Atom core. The way Intel has been avoiding that issue is...well... by avoiding it

 

[wsw1982]

Actually, I think probably a better configuration would be two Haswell + HT cores, and four smaller Atom cores. Similar to how it is looking like Haswell's IGP is going to go very wide, but slow.



Actually, Intel is doing something similar (if the rumors are true) with its IGP. More shaders at a lower clockspeed is a very similar strategy to this, except in this case you have entire cores dedicated to low power.

Unless you are claiming Intel has somehow managed to design a CPU that can cover over an order of magnitude of TDP. Even if Haswell is designed for 8W ~ 80W, 8W is a lot of power for a tablet or smartphone. While I doubt we'll see such a design in desktops or even laptops, for tablets (which typically for Intel carry a much larger margin anyway) I wouldn't be surprised. Intel has already (ok, not already, but supposedly) shown us it is willing to eat die space for power savings.

Of course, if you are correct and Atom embarrasses ARM's offerings (I won't agree or disagree with you there, we're just too far away from release at this point), then Intel wont' have much reason to go this route.

The 8W is the full loading power consumption, which will be matching with the big core in ARM, the idle power consumption is what compare to the little core. And no one knows that yet other than 20X less than sandy bridge.

 

[t0mt0m]

3-4 years on - what happened to this? Could Intel make a CPU with one core that's the main more powerful one for single threaded work, then smaller less powerful cores for multithreaded work? Nothing like big.little done with Intel?

 

[jpiniero]

3-4 years on - what happened to this? Could Intel make a CPU with one core that's the main more powerful one for single threaded work, then smaller less powerful cores for multithreaded work? Nothing like big.little done with Intel?

Windows doesn't support it so it doesn't really matter what Intel thinks of the concept.

 

[Exophase]

Sure are some great retrospectives from reading this thread. People really thought Intel was going to take over the smartphone market by 2015.

3-4 years on - what happened to this? Could Intel make a CPU with one core that's the main more powerful one for single threaded work, then smaller less powerful cores for multithreaded work? Nothing like big.little done with Intel?

The big.LITTLE concept has never really been about improving throughput. Most workloads on the devices it targets just don't scale in a way that would get better performance out of many smaller and more efficient cores. For workloads like that Intel pushes Xeon Phi instead, which can be paired with a conventional Xeon in the same system for a setup like you're talking about.

In theory the main differentiation between Atom and the Core-series CPUs was supposed to be power efficiency, with Atom making the most sense in phones and tablets. In practice, the biggest differentiation seems to have always been price. That's not to say Atom cores don't have a perf/W advantage for at least some part of the perf curve, this just doesn't seem to be their real market driver.

Atom continues to do poorly in the phone market and Intel is consequently losing more and more interest. It only really does okay in markets where it's found in cheaper devices than Core alternatives. Like the lower end tablets, laptops/convertibles and desktops. Even the server-oriented Atom SoCs are more about cost value vs Xeon D than efficiency.

They could do an SoC with 2 Skylake + 2 Airmont cores if they wanted to. But those Airmont cores aren't really that tiny, not compared to Cortex-A53s. And they have a decent minimal cache footprint. There'd need to be a lot of added plumbing to make that work right (this is something that came easier to ARM from the get go because they've always designed with modularity in mind). It'd be a big design effort that would only really kind of sort of make sense for Surface-like tablets, so a relatively small market for a chip that'd be substantially larger than the normal 2 core Skylakes. Low volume, larger chip, substantial added R&D all add up to a big price premium. I doubt the market demand would justify it.

Maybe if there was a serious shot of getting such a thing in phones and taking any real market share it could be on the table.. but that's just not looking like it's going to happen.

 

[DrMrLordX]

woo heck of a necro there. Interesting to see how some of the projections in this thread about the future of Atom did not turn out so well.

Sure are some great retrospectives from reading this thread. People really thought Intel was going to take over the smartphone market by 2015.

Ugh tell me about it. Now we're stuck with the encroaching ARMy.