Increased Dynamic Range: Understanding the Power Profile of Modern SoCs

Section by Anand Shimpi

The iPhone 4S greatly complicated the matter of smartphone power consumption. With the A5 SoC Apple introduced a much wider dynamic range of power consumption to the iPhone than we were previously used to. Depending on the workload, the A5 SoC could either use much more power than its predecessor or enjoy decreased overall energy usage. I began our battery life analysis last time with some graphs showing the power savings realized by a more power hungry, faster CPU.

The iPhone 5 doesn't simplify things any more. I believe the days of us having straightforward discussions about better/worse battery life are long gone. We are now firmly in the era of expanded dynamic range when it comes to smartphone power consumption. What do I mean by that? The best way to explain is to look at some data. The graphs below show total device power consumption over time for a handful of devices running the Mozilla Kraken javascript benchmark. Kraken is multithreaded and hits the CPU cores fairly well. The power profile of the benchmark ends up being very similar to loading a very js-heavy web page, although for a longer period of time. All of the device displays were calibrated to 200 nits, although obviously larger displays can consume more power.

Let's start out by just looking at the three most recent iPhone generations:

The timescale for this chart is just how long the iPhone 4 takes to complete the Kraken benchmark. The iPhone 4/4S performance gap feels a lot bigger now going back to the 4 than it did when the 4S launched, but that's how it usually seems to work. Note how tight the swings are between min and max power consumption on the iPhone 4 during the test. As a standalone device you might view the iPhone 4 as being fairly variable when it comes to power consumption but compared to the 4S and 5 it might as well be a straight line.

The 4S complicated things by consuming tangibly more power under load than the 4, but being fast enough to complete tasks in appreciably less time. In the case of this Kraken run, the 4S consumes more power than the 4, however it's able to go to sleep quicker than the 4 and thus draw less power. If we extended the timeline for the iPhone 4 significantly beyond the end of its benchmark run we'd see the 4S eventually come out ahead in battery life as it was able to race to sleep quicker. The reality is that with more performance comes increased device usage - in other words, it's highly unlikely that with a 50% gain in performance users are simply going to continue to use their smartphone the same way as they would a slower device. Usage (and thus workload) doesn't remain constant, it's somewhat related to response time.

The iPhone 5 brings new meaning to device level power consumption. With a larger display and much more powerful CPU, it can easily draw 33% more power than the 4S under load, on average. Note the big swings in power consumption during the test. The A6 SoC appears to be more aggressive in transitioning down to idle states than any previous Apple SoC, which makes sense given how much higher its peak power consumption can be. Looking at total energy consumed however, the iPhone 5 clearly has the ability to be more power efficient on battery. The 5 drops down to iPhone 4 levels of idle power consumption in roughly half the time of the iPhone 4S. Given the same workload that doesn't run indefinitely (or nearly indefinitely), the iPhone 5 will outlast the iPhone 4S on a single charge. Keep the device pegged however and it will die quicker.

Out of curiosity I wanted to toss in a couple of other devices based on NVIDIA and Qualcomm silicon to see how things change. I grabbed both versions of the HTC One X:

The Tegra 3 based One X actually performs very well in this test, but its peak power consumption is significantly worse than everything else. It makes sense given the many ARM Cortex A9 cores built on a 40nm G process running at high clock speeds on the Tegra 3.

The 28nm Snapdragon S4 (dual-core Krait) based One X gives us some very interesting results. Peak power consumption looks identical to the iPhone 5, however Apple is able to go into deeper sleep states than HTC can with its S4 platform. Performance is a little worse here but that could be a combination of SoC and software/browser. I used Chrome for all of the tests so it should be putting Android's best foot forward, but the latest update to Safari in iOS 6 really did boost javascript performance to almost untouchable levels.

At the end of the day, the power profile of the iPhone 5 appears to be very close to that of a modern Snapdragon S4 based Android smartphone. Any battery life gains that Apple sees are strictly as a result of software optimizations that lead to better performance or the ability to push aggressively to lower idle power states (or both). It shouldn't be very surprising that these sound like a lot of the same advantages Apple has when talking about Mac battery life as well. Don't let the CPU cores go to sleep and Apple behaves similarly to other device vendors, but it's really in idle time or periods of lighter usage that Apple is able to make up a lot of ground.

There's one member of the modern mobile SoC market that we haven't looked at thus far: Intel's Medfield. The data below isn't directly comparable to the data above, my measurement methods were a little different but the idea is similar - we're looking at device level power consumption over time while Kraken runs. Here I'm only focusing on the latest and greatest, the Atom based Motorola RAZR i, the Snapdragon S4 based Droid RAZR M and the iPhone 5. The RAZR i/M are nearly identical devices making this the perfect power profile comparison of Atom vs. Snapdragon S4. The RAZR i is also the first Atom Z2460 based part to turbo up to 2.0GHz.

Very interesting. Atom is the only CPU that can complete the Kraken benchmark in less time than Apple's Swift. Peak power consumption is definitely higher than both the Qualcomm and Apple devices, although Intel's philosophy is likely that the added power usage is worth it given the quicker transition to idle. Note that Atom is able to drive to a slightly lower idle level than the Snapdragon S4, although the Swift based iPhone 5 can still go lower.

At least based on this data, it looks like Intel is the closest to offering a real competitor to Apple's own platform from a power efficiency standpoint. We're a couple quarters away from seeing the next generation of mobile SoCs so anything can happen next round, but I can't stress enough that the x86 power myth has been busted at this point.

I will add that despite Intel's performance advantage here, I'm not sure it justifies the additional peak power consumption. The RAZR i ends up being faster than the iPhone 5 but it draws substantially more power in doing so, and the time savings may not necessarily offset that. We'll see what happens when we get to our battery life tests.

 

GPU Analysis/Performance Battery Life
Comments Locked

276 Comments

View All Comments

  • themossie - Tuesday, October 16, 2012 - link

    The manufacturer's charger uses a set of pull-up resistors connected between the various USB lines, to indicate that the phone can pull maximum current. Unfortunately, every manufacturer (and sometimes different phones) use different resistances.

    See http://electronics.stackexchange.com/questions/144... for a brief writeup.

    For what it's worth, I've only had this problem with iDevices and the HP Touchpad. I own circa-2011+ HTC, Motorola and Samsung phones, and they all work fine with every charger. My Droid 2 Global was my primary work phone until a few months ago, and works great with every charger. Not sure why your wife is having problems there.
  • crankerchick - Tuesday, October 16, 2012 - link

    "The non-LTE phones see a sharp drop in battery life. At least at 28nm the slower air interfaces simply have to remain active (and drawing power) for longer, which results in measurably worse battery life. Again, the thing to be careful of here is there's usually a correlation between network speed and how aggressive you use the device. With a workload that scaled with network speed you might see closer numbers between 3G and 4G LTE."

    Perhaps you all could devise a test for this? Something like, change your LTE and 3G tests, where you decrease the time between page loads for the LTE test, to simulate doing more browsing since the pages load faster? One data point on this, with a reasonably selected change in page load duration, would be very helpful now that we have this very interesting dynamic clearly visible.

    That said, as always, I appreciate the reviews presented here. Always thorough with lots of information to chew on beyond specs and "user opinion on user experience."

    Just wish the reviews didn't take so long, but they are always worth it in the end.
  • TofDriver - Tuesday, October 16, 2012 - link

    Thanks for this awesome article. Gigantic work, we'll worth the wait.
    I've learnt so much.
    Would still appreciate it as an ebook, even after the web reading!
    Seems like you're perfectionists who love to push limits... To me it does resonate with the team who designed the reviewed product.
  • name99 - Tuesday, October 16, 2012 - link

    "Another potential explanation is that the 3-wide front end allowed for better utilization of the existing two ALUs, although it's also unlikely that we see better than perfect scaling simply due to the addition of an extra decoder."

    Remember the standard numbers. On this type of integer code:
    1/6 instructions are branch
    1/6 instructions are store
    1/3 instructions are load
    1/3 instructions are ALU
    This means the usual first throttling point i cache access, if you can only do one load/store cycle.
    If you limit your cache to one op/cycle, it's generally not worth going beyond 2-wide --- too often you're waiting on the cache.
    Once you widen your cache (usually, at this stage, by allowing simultaneous read and write per cycle) three-wide makes sense.
    Each cycle now (on ideal and some sort of "average" idealized code) you can now do some sort of combination of half a branch, 1.5 load/stores, and 1 ALU. Meaning that 2 ALUs (as long as they are not overloaded and also handling some aspect of the load/store) is enough for now.
    [Of course things never work out quite this ideal --- you have burstiness in operation types, not to mention delays. But the compiler should try to schedule instructions to get this sort of average, and likewise the re-order queues will do what they can to shuffle things to this sort of average. 2ALUs helps with the bursts, 3ALUs is overkill.]

    So I would say the primary important change made to go to three-wide in a way that is not a waste of time was to convert the L1 cache to dual-ported, supporting simultaneous load & store per cycle.
  • jiffylube1024 - Tuesday, October 16, 2012 - link

    I have to commend the Anandtech team for the great review! It was a long wait, but well worth it. The info on anodizing, the "Swift" CPU @ 1.3 GHz, camera performance, etc. was worth waiting for. This article, in my eyes, is a culmination of the Anandtech team's knowledge in the tech industry - deconstructing A6 to figure out what it's made of, discussing Apple's manufacturing capabilities, etc. Very informative and well written!

    I am always amazed at how many complaints (and petty platform wars) get exposed on the comment board. I certainly appreciate them when an article is poorly written, contains false information or outright lies, but with an article like this, the comments section seems shy of the effusive praise it deserves!
    ------

    On a slight tangent, I've enjoyed the first 8 Anandtech podcasts as well, and I have to say that I look forward to more non-iPhone related disucssion on future podcasts. The information was much appreciated, but for a tech site as broad as Anandtech, the first 8 podcasts have been VERY iPhone heavy in their content! Keep up the good work.
  • jamyryals - Thursday, October 18, 2012 - link

    I think you're right, it has been iPhone heavy, but the start of the podcast kind of lined up with the launch/review process. Let's be honest, it is a huge selling high quality device and it's treated as such. I have a feeling Brian and Anand will have a lot to say about all of the impending Nexii/WP8 when they come out this quarter.
  • krumme - Tuesday, October 16, 2012 - link

    Good to see reviewers apreciation of low light capabilities for the BSI sensor, reflecting real world usage. Oposite to a lot of uninformed stupid reviews on the net.

    Its exactly the same practical difference between s2 and s3 cameras. Big difference for real usage.

    All the mpix race must stop now. 8M is way to much for the quality anyway.
  • Zanegray - Tuesday, October 16, 2012 - link

    I love the level of analysis and attention to detail. Keep it up!
  • mrdude - Tuesday, October 16, 2012 - link

    Wow, what an article. Really fantastic read. The lengths you guys have gone to in this review is stunning, frankly. Well done. Although I'm no Apple fanatic, I must say that this is one of the better articles I've read on AT :)
  • Dennis Travis - Tuesday, October 16, 2012 - link

    Totally outstanding review. You guys covered everything. Thanks so much!

Log in

Don't have an account? Sign up now