Slashdot Mirror
ARM's Cortex-A72 and Mali-T880 GPU Announced For 2016 Flagship Smartphones
MojoKid writes ARM's Cortex-A57 is just now starting to break stride with design wins and full-ramp production in new mobile products. However, ARM is releasing a wealth of information on its successor: the Cortex-A72. ARM is targeting a core clock of 2.5GHz for the Cortex-A72 and it will be built using a 14nm/16nm FinFET+ process. Using the Cortex-A15 (NVIDIA Tegra 4, Tegra K1) as a baseline, ARM says that the Cortex-A57 (Qualcomm Snapdragon 810, Samsung Exynos 5433) offers 1.9x the performance. Stepping up to the Cortex-A72, which will begin shipping in next year's flagship smartphones, offers 3.5x the baseline performance of the Cortex-A15. These performance increases are being made within the same power envelope across all three architectures. So in turn, the Cortex-A72 can perform the same workload as the Cortex-A15 while consuming 75 percent less power. Much like the Snapdragon 810, which uses a big.LITTLE configuration (four low-power Cortex-A53 cores paired with four high performance Cortex-A57 cores), future SoCs using the Cortex-A72 will also be capable of big.LITTLE pairings with the Cortex-A53. ARM has also announced its new Mali-T880 GPU, which offers 1.8x the performance of the current generation Mali-T760. Under identical workloads, the Mali-T880 offers a 40 percent reduction in power consumption compared to its predecessor. ARM again also points to optimizations in the Mali-T880 to efficiently support 4K video playback.
They always say things like that, but we just keep using bigger and bigger batteries (partly because of bigger screens) and yet battery life seems to only get worse year after year.
http://www.bloomberg.com/news/...
The source of all our problems is software. And the source of our software problems is the pr***@# $^#*( NO CARRIER
That's all I want to know!
The newer SOCs have two high-performance cores and two low power cores. Like the old quadrajet carburetors, efficiency drops quite a bit when the high-perfomance side kicks in.
That said, the screen and radios take up most of the power for most people. Dim the screen and turn off Bluetooth and WiFi as appropriate, or use power-saving mode to automate that process.
Especially when talking about silicon as versions and die shrinks actually matter e.g. the K1 T132 is project denver which is 64bit and uses a JIT compiler to get speedup while version T124 is the Cortex-A15 R3
interesting thing will be the uptake of unix like OS vs Windows 10 on ARM which is sure to annoy Intel who are loosing market share !
regards
John Jones
Actually, perf per watt, or computations performed using N joules of energy, is frequently better for the bigger cores. That's especially true for newer low-leakage deep submicron process nodes.
I find that if I don't use my phone the battery lasts for days. Whatever happened to those fuel cells that used lighter fluid to power laptops? That's what we need for smartphones. Zippo batteries.
Android holding ARM back.
They have desktop class processors held back by an OS that won't run multiple apps on a screen at once (well without Samsungs extensions it won't). Meanwhile the head of Android is focusing on Chrome at the expense of Android. As if a Chrome wrapper for Android to let it do multiple windows is somehow acceptable!
Its' ridiculous that ARM chips drive > 4K screens and yet Android has the calculator full screen.
And while people and business expect their desktop PCs to be professional and private, Google has made Android into a nasty piece of user tracking spyware thanks to their core ad business.
It's a pity Microsoft invested in Cyanogenmod because that would be the obvious fresh Android candidate to get multiple windows and privacy, the two big weaknesses of Android, to compete in the desktop market. Now with Microsoft's money they are unlikely to tackle the desktop.
What we need is a fork of Android with privacy controls put in and a new design of multiple windows to cope with touch instead of mouse. So no more fiddly maximize buttons, and old WIMP controls, but support for multiple windows.
...now they need to find someone that has a 14nm FinFET process since Intel isn't that interested in selling theirs. That seems to be the biggest issue holding people outside of Intel back these days is I hear a lot of talk about 20nm and smaller, but I'm not seeing much in the way of delivery, products still seem to be 28nm by and large.
I think it may be a bit over optimistic to think that TSMC will be doing 14nm by next year, given their recent history of over promising and under delivering on process technology. Perhaps Samsung will fair better, we'll see.
Like the old quadrajet carburetors, efficiency drops quite a bit when the high-perfomance side kicks in.
Not necessarily. Efficiency can actually increase If the high power cores are able to bring the whole system to a low power state sooner.
When all you have is a hammer, every problem starts to look like a thumb.
Computations per joule is not the relevant measurement. The relevant measurement is hours per charge. If you keep the computations per second below the threshold that the 53s can handle, the big cores never light and the battery lasts longer.
A tractor-trailer gets better mileage per pound than a sedan. So do you drive a big rig to work to save gas?
no, computations per joule is the relevant measurement, because cores can be shut down when not in use. The reason to have the weaker cores is that there is no reason to wake up a bigger core when there is not enough work to do.
No. As the other poster says, these cores consume negligible amounts of power when not in use. The performance per Watt of the bigger cores can often be better, so it can consume less energy to power one of the big cores for 250ms than power the little core for 1s, yet still get the same (or more) work done. If your OS scheduler is able to coalesce events then this can be a big energy saving (and, remember, it's energy not power that matters for battery life: your battery can - more or less - supply a fixed amount of energy per charge).
I am TheRaven on Soylent News
You realize you're claiming that ARM's chip architects are completely wrong and have been for a while now, now? You know they actually measure this stuff before they spend a few billion dollars fabbing chips.
>. can consume less energy to power one of the big cores for 250ms than power the little core for 1s
If you need to do 500 million operations, you're close to to the point where it makes sense to power the faster core, yes. Your phone spends 99% of it's time with picoseconds of CPU work to be done, not seconds or milliseconds of work.
Can I have this part on a $37 Raspberry Pi mod next please?
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
AMD is stuck still at 28 nm while these are 14. Wow.
Even the latest intel ones are all 22 nm
http://saveie6.com/
I know myself I am a geek about technology and what is in the products I buy. But for the most part, I think very few consumers give a crap about what processor is powering their devices. I think these days priorities are battery life and applications. Even the cheaper smartphones from Microsoft generally give ample performance for what most people use smart phones for. After all, not many really support much multi tasking and operating systems are constantly being tweaked. Not to mention the reality that performances increases might look good on paper. But rarely show up as significant real world improvements.
can't wait for this new BIG.clit pr0n to be released!!!
blah blah blah, everyone keeps saying that, and yet my battery life is always better when I keep the CPU max clock at about 80% of full speed.
I'm sorry, but physics are a bitch, and you are too for claiming that power doesn't follow the cube of voltage in SoCs. (yes, cube. It follows the cube of voltage, not the I^2R you're used to seeing)
> that it's better to use the little core for long-running tasks that have a lot of I/O and so can't put the core to sleep, but aren't CPU-bound.
If I'm understanding you correctly, you're saying it only saves power to use the little cores if there is io involved, such as a mobile network which is obviously much slower than the CPU cores. Or maybe storage device, like and SD card. Or any user interaction.
You're right, very few things that you do on a mobile phone would involve either the network, the SD card, or the user. My original statement is only true for those few cases. For the NORMAL use of a mobile phone (as a 3D rendering farm), the fat core is better.
If I'm understanding you correctly, you're saying it only saves power to use the little cores if there is io involved, such as a mobile network which is obviously much slower than the CPU cores. Or maybe storage device, like and SD card. Or any user interaction.
No, I'm saying that it saves power to use the little cores if you have a load of interrupts that prevent the core from going to sleep, but are not CPU-bound. For some interactive tasks (lots of moderately demanding apps), you're CPU-bound for short bursts but you can then put the core to sleep and wait.
User interaction is often on a timescale where you can put the core into a low power state while you wait for a ponderously slow user (in comparison to CPU speeds) to press a button. Simple animations can run on the GPU with no CPU involvement at all. When the user presses a button (or the screen), you wake up and do something quickly, then go back to sleep. The big core is often better for this.
The little core is better for things that you can't complete early and then sleep. The mobile network and SD card are terrible examples for your facetious little rant: they both deliver bursts of data tied to an interrupt, so are often ideal for the big core, depending on how quickly the big core can enter a low power state. The best example for the little core is mostly GPU-bound games that have a render loop that requires very frequent CPU-driven updates but without much work being done on the CPU each iteration. There isn't a long enough pause between each one to be able to enter a low power state, but if the A7 can keep up with the demand then it will be more power efficient.
If the world were as simplistic as you're trying to make it out to be, there'd be no point in putting the big cores on at all. Before you try to sound patronising again, please go and read some of ARMs docs. They cover all of this, in a lot of detail, and list some open problems (some of which they're talking to us about on a fairly regular basis).
I am TheRaven on Soylent News
>. Before you try to sound patronising again,
Sorry about that.
If I'm NOW understanding you correctly, you're saying that the big core is better IF the pause is long enough to enter low-power and sleep long enough to make it worth it, correct? Further, I'm reading between the lines and thinking you're saying that on a phone, that's normally the case - that the 53 cores aren't used often, or shouldn't be. Is that correct?
Right, you own a phone so you're an expert :)
Keep in mind that the power management software in your phone may suck and fall short of achieving all the efficiencies that the hardware is capable of. BTW, it is not necessary to lecture me about power curves, far from it.
When all you have is a hammer, every problem starts to look like a thumb.
It should be noted that most programmers will never write or directly use a lockless multithreaded algorithm. The number of things on a phone or tablet that need (or even would benefit significantly from) such an algorithm is relatively small.
Most of the time I suspect that the various cores on a mobile device are doing independent things. The percentage of time that the average phone/tablet is going to be doing massively parallel cpu-bound work is tiny.
Read the datasheets and whitepapers from the battery manufacturers. Charging them too slowly isn't good for them...plus it makes it harder to figure out when they're fully charged.
no, I studied electrical engineering at a school that's probably ranked much higher than yours, and advanced semiconductor fundamentals was my second favorite class, and embedded microcontroller design was my 3rd favorite class.
in addition if what these clowns said were worth listening to, I wouldn't achieve lower idle battery drain by setting a low max-screen-off-frequency.
EEs are famous for thinking they have a clue about software :)
When all you have is a hammer, every problem starts to look like a thumb.
Yay! Intel better spend more money to subsidize their mobile CPUs
Computations per joule is not the relevant measurement. The relevant measurement is hours per charge. If you keep the computations per second below the threshold that the 53s can handle, the big cores never light and the battery lasts longer.
A tractor-trailer gets better mileage per pound than a sedan. So do you drive a big rig to work to save gas?
If you never tax the motor of your sedan to save gas, why didn't you buy one with a smaller motor in the first place?
Of course news about a fake are Fake News.
my job title is software engineer and I've written several drivers that have 100% up-time in multi-million dollar production deployments so...?
So you most probably overestimate your ability in power management. Think about what might be necessary to achieve a win from sprint-to-power-save, and why the phone you own might not implement that. Think about the whole system.
When all you have is a hammer, every problem starts to look like a thumb.
yes, I'm just saying the marketers and pedants claiming that TECHNICALLY it CAN save power, are overrated
If you want to kick somebody's butt about it, aim in the general direction of Qualcomm, not marketing but engineering.
When all you have is a hammer, every problem starts to look like a thumb.