Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

big.LITTLE: ARM's Strategy For Efficient Computing

Soulskill posted 1 year,15 days | from the i-see-what-you-did-there dept.

Hardware 73

MojoKid writes "big.LITTLE is ARM's solution to a particularly nasty problem: smaller and smaller process nodes no longer deliver the kind of overall power consumption improvements they did years ago. Before 90nm technology, semiconductor firms could count on new chips being smaller, faster, and drawing less power at a given frequency. Eventually, that stopped being true. Tighter process geometries still pack more transistors per square millimeter, but the improvements to power consumption and maximum frequency have been falling with each smaller node. Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace. This is a critical problem for the mobile market, where low power consumption is absolutely vital. big.LITTLE is ARM's answer to this problem. The strategy requires manufacturers to implement two sets of cores — the Cortex-A7 and Cortex-A15 are the current match-up. The idea is for the little cores to handle the bulk of the device's work, with the big cores used for occasional heavy lifting. ARM's argument is that this approach is superior to dynamic voltage and frequency scaling (DVFS) because it's impossible for a single CPU architecture to retain a linear performance/power curve across its entire frequency range. This is the same argument Nvidia made when it built the Companion Core in Tegra 3."

cancel ×

73 comments

big.LITTLE is a joke (0)

Anonymous Coward | 1 year,15 days | (#44235167)

It's a way for ARM to double their royalty per chip while also doubling the leakage power.

Re:big.LITTLE is a joke (3, Insightful)

Anonymous Coward | 1 year,15 days | (#44235261)

Powered-down circuits have no leakage. Also a "little" implementation has vastly lower leakage than a bigger core.

Re:big.LITTLE is a joke (3, Informative)

AlecC (512609) | 1 year,15 days | (#44235789)

Royalties in many licenses allow an unlimited number of CPUs on the same chip. You pay the royalty per design per chip.

Power not die area efficient. (1)

Anonymous Coward | 1 year,15 days | (#44235197)

This solution _might_ be more power efficient. But it can not be more die and space efficient. Looking at keeping die sizes down to place more other crap on the die's, a ginormous core complex does not really fit the bill. Besides, if you want to keep core context switch times low, you must keep all caches etc on the larger cores hot and that draws power. This solution probably fits when you start a game, so that you have an explicit trigger to switch to the larger cores. If you are talking on demand ultra low latency switches, then again, keeping those cores hot costs power.
An asymmetric SMP machine is nothing new. An on-demand asymmetric SMP machine is something different however.
I still maintain that single-threaded performance (with a properly implemented, non retarded OS) far outweighs multi-threaded performance, so making an effort to starve those larger cores and still maintain power budget is probably the best bet anyway. (Intel x86).

Re:Power not die area efficient. (4, Insightful)

TheRaven64 (641858) | 1 year,15 days | (#44235447)

This solution _might_ be more power efficient. But it can not be more die and space efficient

Two words: Dark Silicon. As process technologies have improved, the amount of the chip that you can have powered at any given time has decreased. This is why we've seen a recent rise in instruction set extensions that improve the performance of a relatively small set of algorithms. If you add something that needs to be powered all of the time, all you do is push closer to the thermal limit where you need to reduce clock speed. If you add something that is only powered infrequently, then you can get a big performance win when it is used but pay a price when it isn't.

TL;DR version: transistors are cheap. Powered transistors are expensive.

Re:Power not die area efficient. (1)

RoboJ1M (992925) | 1 year,15 days | (#44235703)

Agreed.
If there is ever the perfect fits all solution (such as Intel tries to build) it won't be for a very long time. If ever.
Transistors are cheap, just built for what your target usage is.
I seem to remember something about AMD and some sort of interconnect tech that (one day) allows you to quickly/cheaply/easily interconnect modular chip bits and really easily build for a target market.

Re:Power not die area efficient. (1)

SuricouRaven (1897204) | 1 year,15 days | (#44235671)

At 28nm? It's the difference between 'tiny' and 'almost as tiny.' The packaging is many times the size of the chip, so if you can get both chips in one package it won't add anything. Power is more important.

Re:Power not die area efficient. (0)

Anonymous Coward | 1 year,15 days | (#44236259)

I hope you know that the die is not 28nm big.

Re:Power not die area efficient. (3, Informative)

RoboJ1M (992925) | 1 year,15 days | (#44235755)

Found it:

http://semiaccurate.com/2013/05/01/sonics-licenses-fabric-tech-to-arm/ [semiaccurate.com]

"Sonics and ARM just made an agreement to use Sonics interconnects patents and some power management tech in ARM products."

"If Sonics is to be taken at face value on their functionality, then you can slap just about any IP block you have on an ARM core now with a fair bit of ease."

This is kind of relevant too, the internet will eat all our electricities:

http://www.theregister.co.uk/2012/11/26/interview_rod_tucker/ [theregister.co.uk]

"and if we don’t do anything, it could become ten percent between 2020 and 2025"

Although if you read it, the lion shares of internet electric usage is actually those amp happy DSL connections we have.

Re:Power not die area efficient. (1)

RoboJ1M (992925) | 1 year,15 days | (#44235761)

Whoops, replied to the wrong message...

Re:Power not die area efficient. (1)

K. S. Kyosuke (729550) | 1 year,15 days | (#44237071)

An asymmetric SMP machine is nothing new.

That's a tautology. An asymmetric symmetric multiprocessor can't exist by definition, therefore it can't exist as a new thing by definition.

Re:Power not die area efficient. (0)

Anonymous Coward | 1 year,15 days | (#44237765)

An asymmetric SMP machine is nothing new.

That's a tautology. An asymmetric symmetric multiprocessor can't exist by definition, therefore it can't exist as a new thing by definition.

SMP refers to the architecture of the system, asymmetric (in this case) refers to the micro-architecture of the individual processors. As long as the processors have the same architecture then they can support SMP even if they have different micro-architectures.

old news (3, Informative)

Anonymous Coward | 1 year,15 days | (#44235203)

Advertising much?

Re:old news (0)

Anonymous Coward | 1 year,15 days | (#44239947)

Welcome to Slashdot. The news from last year, today.

This Looks Familiar... (0)

Anonymous Coward | 1 year,15 days | (#44235207)

I can imagine the comments made to 3dfx Interactive back in the day:
"Wait wait wait, you mean that it's better to create a SEPARATE processing unit to handle graphics? Why not just lump it all on the CPU? You're crazy!!!"

Use the best tool for the best job I suppose.

Re:This Looks Familiar... (2)

Rockoon (1252108) | 1 year,15 days | (#44235301)

GPU caches are designed to maximize bandwidth.
CPU caches are designed to minimize latency.

These two goals are at odds with each other.

It is no surprise that there is a market for GPU's. I think the surprise was that 3dfx could offer much-better-than-using-the-cpu performance so cheaply.

big.LITTLE (1)

Rosco P. Coltrane (209368) | 1 year,15 days | (#44235239)

Some marketdroid had a field day finding that name, sheesh...

I would have added "i" in front of it, personally. Everybody knows i-anything is teh kewl these days.

Re:big.LITTLE (4, Funny)

Thanshin (1188877) | 1 year,15 days | (#44235275)

Are you proposing the name IBig.ULittle?

Re:big.LITTLE (1)

Anonymous Coward | 1 year,15 days | (#44235357)

How about LITTLE.big:ARM-venture.

Re:big.LITTLE (1)

ebno-10db (1459097) | 1 year,15 days | (#44236317)

Code name the next ARM architecture "horn". Then you can have little.BIG.horn (ducks to avoid arrows).

with apologies to the Pythons (1)

Anomalyst (742352) | 1 year,15 days | (#44241551)

are you making fun of my product LITTLE.biggusdickus?

Car analogy (1)

Chrisq (894406) | 1 year,15 days | (#44235311)

Its like a hybrid vehicle, when you only need to go slow it runs on a small motor, when you need power the big engine kicks in but needs more juice.

Re:Car analogy (0)

Anonymous Coward | 1 year,15 days | (#44235351)

And overall it performs very baddly :)

Re:Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44236085)

Is that so? ;)

Mercedes Benz E300 BlueTEC Hybrid 65 mpg 111 g/km (201bhp 2.1l)
Peugeot 3008 Hybrid4 74 mpg 99g/km (200bhp 2.0l)

The Prius is old news.

Re:Car analogy (1)

wagnerrp (1305589) | 1 year,15 days | (#44236451)

Yes. If you're putting a 200hp engine in a hybrid designed for use as a passenger vehicle, you're doing it wrong. The engine only needs enough power to resist rolling friction and drag at highway speeds. Somewhere around 30-50hp would be plenty. When you need acceleration, you rely on the big motor.

Re:Car analogy (1)

squizzar (1031726) | 1 year,15 days | (#44236667)

So basically a KERS type system? e.g. a small ICE for range and a much more powerful electric/flywheel motor for acceleration? Depending on usage that may make more sense than the current system. An ICE that can sustain say 90mph whilst still providing some left over energy to be stored for acceleration. Worst case is you do lots of high speed starts and stops (e.g. driving like a tool in traffic or urban areas) which leaves you with only the ICE power - which would likely still be enough for most purposes.

Re:Car analogy (1)

wagnerrp (1305589) | 1 year,15 days | (#44237259)

A sufficiently large electric motor would have the power to capture most of your braking energy at typical urban speeds, and even if it weren't, you're stopping because of stop signs and traffic lights. You've got plenty of time when the car is sitting idle, using no energy, to rebuild your buffer, assuming you're using a proper electric transmission, and not one of these worthless hybrids that keeps the engine mechanically coupled to the drive train. The only value of a hybrid in a car is when you're actually a race car, you need high sustained power output, and it doesn't make sense to have a decoupled engine and a large generator due to weight constraints.

Re:Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44238213)

I've wondered why they haven't done that yet.
Both the cars I've mentioned have something similar.
No expensive complex linkage in the 3008 (diesel front, electric rear)
No expensive batteries or big electric in the Merc (electric just there to maintain 70mph)
There is one boutique sports car with an engine that is just a generator.
So give it another 10 years.

Re:Car analogy (0)

Anonymous Coward | 1 year,15 days | (#44245421)

You've got plenty of time when the car is sitting idle, using no energy, to rebuild your buffer, assuming you're using a proper electric transmission, and not one of these worthless hybrids that keeps the engine mechanically coupled to the drive train.

You really ought to learn more about the "worthless hybrids" you denigrate. Toyota Hybrid Synergy Drive, for example, is capable of recharging the battery while at a stoplight despite supporting mechanical coupling of the ICE to the wheels. Planetary gear transmissions are nifty.

Re:Car analogy (1)

wagnerrp (1305589) | 1 year,15 days | (#44245761)

In other words, in order to overcome an inherent flaw in the design, they had to come up with a convoluted gearbox that needs a substantial third motor just to manipulate the ratios between two others and the output. That's not a marvel. That's just engineers doing their best to mitigate poor decisions made higher up.

Re:Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44238179)

The merc's like that, except backwards.
Diesel to get up to speed and electric to keep you there, charging from the diesel when the small battery is flat.
Clever sticks those Germans.

Re:Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44238163)

I'm not sure but I think they're summing the power of the dino engine and the electric engine.
I have the same engine in my Ford and it puts out 138bhp (It's an engine by PSA)
However the diesel powers the front wheels and the electric the rear.
This allows you to use both at the same time and forgo the heavy, complex and expensive linkage in normal hybrids.
Thing is, if it only produces 99 g/km.

Now, the Merc is quite different, the electric engine is small, as is the battery and it's packed somewhere in the transmission.
On the Merc, at motorway speeds the diesel engine is shutdown and the electric is used to maintain 70 mph.
When the small battery is exhausted, the diesel cuts in, generates motive power and electrickery until the battery is full again.
Which is how a 200hp engine produces only 111 g/km.

With the Peugeot you can drive with either engine or both for bursts of power.

Peugeot's my preferred solution. Simple, cheap (er), flexible (2wd, 4wd, electric, diesel or both) and efficient (electric at low speeds, either at high speeds)
I think I'll get one next year when the '11 plates are out of warranty and cheap (45% of showroom cost)
Also you get 200bhp in what is (I think) a road tax exempt car (100 g/km, although that's a number that goes down as years go by)

Re:Car analogy (1)

wagnerrp (1305589) | 1 year,15 days | (#44238665)

However the diesel powers the front wheels and the electric the rear.

Which means the diesel is still mechanically connected to the road. Either you have an incrementally variable transmission, and chances are the diesel is not going to be running anywhere near its optimal conditions, or you have a continuously variable transmission, in which case you've got tons of losses anyway. The whole point of an electric transmission is to allow the engine to operate in the narrow band it wants to, and use the electric motor to provide the wide, efficient operating range you need.

Re:Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44239095)

There's one car like that, some boutique sports car.
Of course, there's no reason why you can't just have the car disengage the clutch and charge the battery that's in the boot.
For reference the transmission is an "electrically controlled manual".
Assuming this means 6 speeds and clutch but electronic auto/semi controlls.
So, use the diesel to accelerate up to 88 miles and hour.
Then disengage the clutch, shutdown the diesel and maintain with the electrics.
When you're out of leccy, start up the diesel and charge the battery with it at whatever is the most efficient RPM for the diesel.
Apart from the fact that you're lugging a gearbox and clutch around this seems a good interim solution to me.
Especially as Peugeot say it's very easy to retro fix to existing machine lines and vehicle platforms.

Re:Car analogy (1)

wagnerrp (1305589) | 1 year,15 days | (#44240123)

For reference the transmission is an "electrically controlled manual".

When I say an "electric transmission", I'm referring to a diesel-electric drive, where a diesel engine powers a generator which powers one or more motors. The electrical wiring replaces the traditional mechanical linkages in the transmission.

Re: Car analogy (1)

RoboJ1M (992925) | 1 year,15 days | (#44241043)

Yes I realised, the statement about the gear box was unrelated.
The reason I mentioned the gearbox was because with it it's possible to electrically disengage the clutch, there's no clutch pedal. Meaning with appropriate firmware it can run as a diesel electric drive system. I think I'll ask them.
Anyway, I've found my next car! 8D
They come into my price range next year.

Re:Car analogy (0)

Anonymous Coward | 1 year,15 days | (#44235475)

And similarly, it's going to be sneered at by people using high-performance vanity machines who can't see where the wind is blowing.

It's not necessarily ARM's solution (5, Insightful)

m6ack (922653) | 1 year,15 days | (#44235347)

Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel.

So, not all ARM licensees have been convinced or seen the need to go to a big/little architecture because big/little has that big disadvantages of added complexity and wasted realestate (and cost) on the die. Unlike nVidea (Tegra) and Samsung (Exynos), Qualcomm has been able to thus far keep power under control in their Snapdragon designs without having to resort to a big/little and has thus been able to excel on the phone. So far, the Qualcomm strategy seems to be a winning one for phones in terms of both overall power savings and performance per miliwatt -- where on phones every extra hour of battery life is a cherished commodity. Such may not be true for tablets that can stand to have larger batteries and where performance at "some reasonable expectation" of battery life may be the more important.

Re:It's not necessarily ARM's solution (-1)

Anonymous Coward | 1 year,15 days | (#44235403)

Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel.

Yeah, too bad there's no way to have clock scaling and big/little on the same SOC. Oh, wait, that's exactly what big/little SOCs have.

Re:It's not necessarily ARM's solution (1)

gl4ss (559668) | 1 year,15 days | (#44235425)

it's still lazy and ends up with juggling between the two cores, but that's not arms problem so they went with it.

but this is prett much the 4+1 core solution from nvidia anyways. it would be far better if they could just shut down parts of the one core to stop leakage. article blurb is just stupid though, it implies this would be a way towards cheaper, while it obviously isn't since it uses more die space.

Re:It's not necessarily ARM's solution (5, Insightful)

TheRaven64 (641858) | 1 year,15 days | (#44235497)

The power difference between an A7 and an A15 is huge. There's really nothing that you could do to something like an A15 to get it close to the power consumption of the A7 without killing performance. They're entirely different pipeline structures (in-order, dual-issue-if-you're-luck vs out-of-order multi-issue). The first generation from Samsung had some bugs in cache coherency that made them painful for the OS, but the newer ones are much better: they allow you to have any combination of A7s and A15s powered at the same time, so if you have a single CPU-bound task you can give it an A15 to run on and put everything else on one or more A7s (depending on how many other processes you've got, running multiple A7s at a lower clock speed may be more efficient than running one at full speed). The OS is in a far better place to make these decisions than the CPU, because it can learn a lot about the prior behaviour of a process and about other processes spawned from the same program binary.

Re:It's not necessarily ARM's solution (1)

squizzar (1031726) | 1 year,15 days | (#44236801)

I'm glad someone else pointed this out. The OP's complaint makes it sound like we're going to run out of silicon if we use too much. Also the 'juggling between cores not being ARM's problem' bit doesn't make a lot of sense: ARM have an awful lot of interest in producing something that provides a real-world performance/power envelope that is attractive to their customers. If, due to the complexity of operating the chip or some other factors, this is not practical or possible, the chip won't sell. It's suggesting that the likes of Samsung, Apple, HTC, Nokia, LG, Sony and many others just pick the chip because it had good marketing rather than a detailed analysis of the performance against the expected uses of the device.

Re:It's not necessarily ARM's solution (1)

Anonymous Coward | 1 year,15 days | (#44245829)

It's suggesting that the likes of Samsung, Apple, HTC, Nokia, LG, Sony and many others just pick the chip because it had good marketing rather than a detailed analysis of the performance against the expected uses of the device.

Er, dunno if you'd noticed, but Apple actually rejected big.LITTLE. Apple used ARM's Cortex-A9 design in the Apple A5/A5X chips, but in A6/A6X, rather than upgrading to a big.LITTLE A7/A15 pair, they switched to their own custom ARM core design. It isn't quite as fast as A15, but supports a wider dynamic range of power/performance operating points (including A7-like power at the low end). As A15's max performance is only available at unsustainable (for tablets and phones, anyways) power consumption levels, beating it doesn't matter that much to Apple.

Similar comments apply equally well to Qualcomm. Qualcomm ships ARM-designed ARM cores in their low end SoC products, but their high end products are based on custom Qualcomm CPU core designs and do not feature anything akin to big.LITTLE. Qualcomm SoCs are frequently used by Samsung Mobile (which doesn't always pick Samsung Semiconductor SoCs!), Nokia, HTC, LG, Sony, and so forth.

Re:It's not necessarily ARM's solution (0)

Anonymous Coward | 1 year,15 days | (#44239623)

i think the reason for that is arm's power plane control is not very good if you compare
against intel. arm is trying to say that powering off the whole cpu is better, but i think
in practice one will want finer grained control. what if you want a little more performance
than the LITTLE will give you?

Re:It's not necessarily ARM's solution (1)

ebno-10db (1459097) | 1 year,15 days | (#44236455)

it uses more die space

So? Transistors keep getting smaller. It's worth using more transistors to reduce power consumption. Also this isn't an either/or approach - other power saving tricks can be combined with this.

Moreover, "more die area" means nothing until quantified. How much smaller is an A7 than an A15? What portion of the die area of a SOC is an A7?

Re:It's not necessarily ARM's solution (2)

tlhIngan (30335) | 1 year,15 days | (#44239469)

it's still lazy and ends up with juggling between the two cores, but that's not arms problem so they went with it.

but this is prett much the 4+1 core solution from nvidia anyways. it would be far better if they could just shut down parts of the one core to stop leakage. article blurb is just stupid though, it implies this would be a way towards cheaper, while it obviously isn't since it uses more die space.

Except it's easier in software to use big.LITTLE. If you wanted to switch from A7 to A15 and back, as long as the cores lined up and you had a cache coherent bus (a requirement anyways), all you'd really do was activate the new cores, force a context save on all 4 cores, then restore the context on the new cores. Shut down the old cores, and let the caches in the new cores warm up through cache coherency, then issue one final flush on the old cores and you're done.

As far as the OS is concerned, nothing changed. The scheduler doesn't even need to be super-aware of the change (it could, which makes life easier, but if it isn't, you can use an upper level library to do it underneath the OS).

NVidia's solution requires scheduler awareness, and runs the risk that the +1 is not sufficient to handle existing tasks thus keeping the 4 cores unnecessarily up.

The big problem though isn't power draw - the A15 is a huge power hog, true, but the problem with that is thermal issues.

Yes, thermal. You run 4 A15 cores full tilt and the chip heats up significantly - easily reaching max junction temperature in a few minutes. And there's very little in the way of cooling - you can't have huge heat planes on the PCB because you're talking high-density BGA parts, and the top of the chip is covered by a PoP memory chip.

I've seen thermal analysis done - the best that could be done would be 2 A15s running full tilt, with the other two software-modulated to run under 50% load after a few minutes, which would keep the chip at max temperature. And the system would try to be progressive - as the chip heated up, the cores would increasingly require being idle to maintain thermal limits.

Of course, a few minutes is all you need when you're e-peening GeekBench and other related benchmarks.

Re:It's not necessarily ARM's solution (1)

dgatwood (11270) | 1 year,15 days | (#44240867)

I've seen thermal analysis done - the best that could be done would be 2 A15s running full tilt, with the other two software-modulated to run under 50% load after a few minutes, which would keep the chip at max temperature.

Couldn't that be solved by adding Peltier junctions to cool the cores (albeit at a cost in battery life)?

Re:It's not necessarily ARM's solution (0)

Anonymous Coward | 1 year,15 days | (#44241839)

If you're going to waste space and battery anyway, I have a better idea. Gentlemen, I present to you... The Gatling CPU.

Re:It's not necessarily ARM's solution (1)

K. S. Kyosuke (729550) | 1 year,15 days | (#44237161)

Yeah, too bad there's no way to have clock scaling and big/little on the same SOC.

Clock scaling is almost useless these days, power gating is where it's at.

Frequency scaling is alive and well (0)

Anonymous Coward | 1 year,15 days | (#44237587)

Clock scaling is almost useless these days, power gating is where it's at.

Huh? Both ARM and Intel make heavy use of clock scaling (and voltage scaling) to manage power consumption when lightly loaded.

Re:It's not necessarily ARM's solution (2, Interesting)

Anonymous Coward | 1 year,15 days | (#44235503)

where on phones every extra hour of battery life is a cherished commodity. Such may not be true for tablets that can stand to have larger batteries and where performance at "some reasonable expectation" of battery life may be the more important.

This isn't directly for phones and tablets and it isn't "a lazy way out of the power problem".
We are not talking about a gradual increase in efficiency here, this is to solve the standby energy requirements for permanently powered consumer devices like TV-sets. (See the One Watt Initiative [wikipedia.org] )
The first generation of devices that solved the problem had dual power supplies. One that was optimized for high efficiency for a low load. This was used to power a microcontroller that dealt with the remote control and started the primary power supply and the rest of the electronics.
Later there where pretty large improvements in switched power supplies that made it possible to go back to just having a single transformer.
The problem is that there aren't really any devices in the 32bit-range that can get down below the 1mA-range without being completely shut down. (This isn't just ARM, it's also true for PIC32, ColdFire, AVR32 and other competing controllers, and no, Atom is not even trying to get down in this range.)
Because of this the common solution is to have a small 8bit/16bit controller to handle the standby mode and possibly some of the low latency tasks that the larger controllers have problems with.
The big.LITTLE solution to this problem isn't new, controllers with asymmetric cores have been available for a while. The benefit of it isn't a power saving, it is a space saving. This will allow developers to remove the external controllers.
It also doesn't add complexity compared to a system with multiple controllers that are completely separate form each other.

Re:It's not necessarily ARM's solution (1)

Anonymous Coward | 1 year,15 days | (#44235519)

Lazy and effective is wiser than difficult and effective, every time. When you favour doing a clever design over adding a whole lot of cheap silicon you wind up with unreliable, hard to design, hard to build, hard to write-for monsters like the PS2 and PS3 architectures.

Re:It's not necessarily ARM's solution (0)

Anonymous Coward | 1 year,15 days | (#44235701)

Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode...

And why is this a bad thing? When in low power mode, you usually don't need the compute capacity. Because if you would, well, then you would not be in low power mode. What would you like to fine tune, if not switching off significant parts of the chip? big.LITTLE is a amazingly clever way out of the power problem IMHO.

and... (0)

Anonymous Coward | 1 year,15 days | (#44235443)

If this is effective, what keeps ARM's competition from implementing the same thing?

Re:and... (1)

greentshirt (1308037) | 1 year,15 days | (#44235495)

patents & lawyers

Re:and... (4, Insightful)

TheRaven64 (641858) | 1 year,15 days | (#44235547)

Nothing, except that Intel's most power efficient chips are in the same ballpark as the A15 (the power-hungry, fast 'big' chip) and they currently have nothing comparable to the A7 (the power-efficient, slow 'LITTLE' chip). And in the power envelope of the A7, an x86 decoder is a significant fraction of your total power consumption.

One of the reasons why RISC had an advantage over CISC in the '80s was the large amount of die area (10-20% of the total die size) that the CISC chips had to use to deal with the extra complexity of decoding a complex non-orthogonal variable-length instruction set. This started to be eroded in the '90s for two reasons. The first was that chips got bigger, whereas decoders stayed the same size and so were proportionally smaller. The second was that CISC encodings were often denser, and so used less instruction cache, than RISC.

Intel doesn't have either of these advantages at the low-power end. The decoder is still a significant fraction of a low-power chip and, worse, it is a part that has to be powered all of the time. They also don't win on instruction density, because both x86 and Thumb-2 are approximately as dense.

MIPS might be able to do something similar. They've been somewhat unfocussed in the processor design area for the past decade, but this has meant that a lot of their licensees have produced chips with very different characteristics, so they may be able to license two of these and implement something similar quite easily. Their main problem is that no one cares about MIPS.

Re:and... (0)

Anonymous Coward | 1 year,15 days | (#44235779)

Jeez. Stop peddling that BS for Gods sake. Intel has managed to match A7 power-performance in clovertrail which doesn't even run on the latest intel process technology. Go an read the review on anandtech.com before blabbering ARMH crap. Little-Big design is an admission on behalf of ARM that they cannot match Intel in performance while maintaining the power efficiency. Come Baytrail and ARM wont be able to hide behind such BS anymore

Re:and... (4, Informative)

TheRaven64 (641858) | 1 year,15 days | (#44235831)

Citation needed. Anandtech benchmarked Clovertrail against Tegra-3, the least power efficient ARM core currently on the market. The Tegra-3 has a very power-hungry GPU (which is nice if you've got the batteries for it...) and a fairly standard Cortex A9 core, which has lower performance-per-Watt than either the A7 or A15 and lower performance in absolute terms than the A15. Their latest Atom SoCs are in the same ballpark as the A15 in both power consumption and performance, but they're nowhere near the A7 in terms of power consumption, which uses less power under load than Clovertrail uses idle.

Re:and... (1)

Anonymous Coward | 1 year,15 days | (#44239995)

Covertrail is last gen tech. Its an iteration of the old atom. All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind. It's all been bolt-on tech. These are Intels words.

Baytrail/silvermont;, coming out Q3 this year, will effectively erase any power advantage an Arm SoC. 22nm, designed from the ground up for power savings. 64bit. Quad core. Cheap. Intel fully expects to see sub 200 dollar windows 8 (Not windows RT) tablets.

Re:and... (1)

TheRaven64 (641858) | 1 year,15 days | (#44240217)

So, you're comparing an unreleased product that doesn't yet exist to shipping products and accusing me of spreading BS? And repeating claims that Intel has made about its last three generations of Atoms, which have never yet been true? Okay then, enjoy your bubble.

Oh, this made me laugh:

All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind

The Pentium 4 was the last Intel chip not to be designed from the ground up with power management in mind, at least according to the chief architect of the P4 project when I spoke to him a little while ago.

The n (0)

Anonymous Coward | 1 year,15 days | (#44240243)

Covertrail is last gen tech ... never designed with power mangement ... bolt-on tech. These are Intel's excuses.

FTFY

Truth is that all Atoms have been designed to be power efficient and Intel keeps saying that the next Atom will beat ARM. It hasn't happened yet, but that doesn't mean it won't happen in the future.

Re:and... (0)

Anonymous Coward | 1 year,15 days | (#44235873)

Intel has managed to match A7 power-performance in clovertrail which doesn't even run on the latest intel process technology. Go an read the review on anandtech.com

Could you help us by providing a link. I can't see anything on anandtech.com comparing A7 and clover trail.

The full Moore law (1)

YoopDaDum (1998474) | 1 year,15 days | (#44236545)

In the original 1965 paper Moore was talking about the density of the least-cost process, and this part is often left out when summarizing what Moore's law is. The full more law is "the density of the least-cost process doubles every 18 months". This means that Moore's law can fail in two ways: if we can't get any denser (not yet) or if we can get denser, but not at a lower cost too (now?). The following says that the "full Moore law" stops at 28 nm:

Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace.

The economic part is often left out on tech sites discussions, but it matters a lot. Up to now we had a sustainable situation where the cost of new processes increased regularly, but at the same time eventually the cost of the new process was lower. This allowed to get all on board and to also increase the reachable market, to get more revenues. That's why we have small micro-controllers everywhere nowadays.

Now when the cost of new processes increases, only the part of the market that trully need the improved density and performance will move on. And that's only a small part of the whole market. So we will have increasing costs, with a reducing addressable market. Double whammy. Expect end prices for high performance to rise quickly. That may slow down things significantly.

We'll see how it develops soon, but I would expect the economic to bite before we reach tech limits.

Re:The full Moore law (1)

ebno-10db (1459097) | 1 year,15 days | (#44236887)

20nm wafers won't be cheaper than the 28nm

Won't be, or currently aren't? There's always the possibility of improved 20nm yields.

Re:The full Moore law (1)

marcosdumay (620877) | 1 year,15 days | (#44239813)

It's still too early to declare the end of Moore's Law. If for no other reason, because very few fabs can produce 20nm chips, so nobody can tell if Intel made a mistake somewhere.

Yelds increse through all the life of a fab process, and those 18 monts aren't quite exact. We can still go back to normal.

More efficient programing languages help? (0)

Anonymous Coward | 1 year,15 days | (#44237807)

I was once a programer when i was in High School. Since then I've noticed and been told friend who are programers/coders that programming languages now are sloppy when it comes to memory. I've heard also that old languages like Basic, C and other were better at keeping memory processing needs to a minimum. Would a modern language using the smaller memory/processing requirement help things with ever need come with more efficient chip?

Re:More efficient programing languages help? (1)

Thiez (1281866) | 1 year,9 days | (#44294345)

> I was once a programer when i was in High School. Since then I've noticed and been told friend who are programers/coders that programming languages now are sloppy when it comes to memory.
Garbage-collection performs better when there is more memory available, and many modern languages use garbage-collection. Then we have JIT, which requires a bytecode-compiler and a bytecode-interpreter to be in memory (unless you compile the whole program on startup). Basically we're trading memory for things like safety, platform-independence, and performance (e.g. when caching data). Which usually makes a lot of sense and works very well for powerful systems with a lot of RAM, but not so much in other situations.

> I've heard also that old languages like Basic, C and other were better at keeping memory processing needs to a minimum.
What do you mean by 'memory processing needs'?

> Would a modern language using the smaller memory/processing requirement help things with ever need come with more efficient chip?
Sorry, I can't parse 'help things with ever need come with more efficient chip'.

If you're asking if a theoretical language that uses less memory and (magically) less processing power would remove the need for more efficient chips the answer is 'no'. The advantages of being more efficient are cumulative so until we arrive at the point where our phones have 100-year battery times having both would always be better than having one or none.

wafer prices didn't go down for earlier nodes (1)

Eric Smith (4379) | 1 year,15 days | (#44239697)

The cost of a 45 nm wafer was higher than that of a 65 nm wafer, etc. It was only the cost of an individual die that went down, because with a smaller geometry an equivalent die was smaller, thus there were more of them per wafer.

Simple but effective concept, but I'm biased... (0)

Anonymous Coward | 1 year,15 days | (#44241507)

I'm actually planning to do the same thing at a slightly larger scale with a little two host virtualization cluster at home. One low power host for most of the time when I just need a few VMs with little load, and a second more powerful host to do the heavy lifting when needed. Seems like it should work in theory.

Slashdot, I am disappoint (1)

rwa2 (4391) | 1 year,15 days | (#44242751)

Came here for a companion cube analogy, leaving disappointed :(

ARM (1)

Ratan Gharami (2979397) | 1 year,15 days | (#44244295)

Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel. So, not all ARM licensees have been convinced or seen the need to go to a big/little architecture because big/little has that big disadvantages of added complexity and wasted realestate (and cost) on the die. Unlike nVidea (Tegra) and Samsung (Exynos), Qualcomm has been able to thus far keep power under control in their Snapdragon designs without having to resort to a big/little and has thus been able to excel on the phone. So far, the Qualcomm strategy seems to be a winning one for phones in terms of both overall power savings and performance per miliwatt -- where on phones every extra hour of battery life is a cherished commodity. Such may not be true for tablets that can stand to have larger batteries and where performance at "some reasonable expectation" of battery life may be the more important. http://equipmentbds.blogspot.com/ [slashdot.org] ">please visit it

Re:ARM (0)

Anonymous Coward | 1 year,14 days | (#44247575)

[...] instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel.

Both A7 and A15 have fine-grained power control and are lower power processors in their own right.

just like air conditioning (1)

ecloud (3022) | 1 year,14 days | (#44247497)

The same strategy enabled high-EER air conditioning: use a small compressor which runs most of the time plus a larger one to handle peak cooling loads, rather than an even bigger compressor which cycles on and off frequently.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...