Qualcomm Snapdragon S4 (Krait) Performance Preview - 1.5 GHz MSM8960 MDP and Adreno 225 Benchmarks
by Brian Klug & Anand Lal Shimpi on February 21, 2012 3:01 AM EST- Posted in
- Smartphones
- Snapdragon
- Qualcomm
- Adreno
- Krait
- Mobile
Power Measurements using Trepn
Measuring power draw is an interesting unique capability of Qualcomm's MDPs. Using their Trepn Profiler software and measurement hardware integrated into the MDP, we can measure a number of different power rails on the device, including power draw from each CPU core, the digital core (including video decoder and modem) and a bunch of other measures.
Measuring and keeping track of how different SoCs consumer power is something we've wanted to do for a while, and at least under the Qualcomm MDP umbrella at this point it's possible to measure right on the device.
The original goal was to compare power draw on 45nm MSM8660 versus 28nm MSM8960, however we encountered stability issues with Trepn profiler on the older platform that are still being resolved. Thankfully it is possible to take measures on MSM8960, and for this we turned to a very CPU intensive task that would last long enough to get a good measure, and also load both cores so we can see how things behave. That test is the Moonbat Benchmark, which is a web-worker wraper of the sunspider 0.9 test suite. We fired up a test consisting of 4 workers and 50 runs inside Chrome beta (which is web-worker enabled), and profiled using Trepn.
If you squint at the graph, you can see that one Krait core can use around 750 mW at maximum load. I didn't enable the CPU frequency graph (just to keep things simple above) but is 750 mW number happens right at 1.5 GHz. The green spikes from battery power are when we're drawing more than the available current from USB - this is also why you see devices sometimes discharge even when plugged in. There's an idle period at the end that I also left visible - you can see how quickly Qualcomm's governor suspends the second core completely after our moonbat test finishes running.
Here's another run of moonbat on Chrome Beta where we can see the same behavior, but zoomed in a bit better - each Krait core will consume anywhere between 450 mW and 750 mW depending on the workload, which does change during our run while V8 does its JIT compilation and Chrome dispach things to each CPU.
The next big question is obviously - well how much does GPU contribute to power drain? The red "Digital Core Rail Power" lines above include the Adreno 225 GPU, video decode, and "modem digital" blocks. Cellular is disabled on the MDP MSM8960, and we're not decoding any video, so in the right circumstances we can somewhat isolate out the GPU. To find out, I profiled a run of GLBenchmark Egypt on High settings (which is an entirely GPU compute bound test) and let it run to completion. You can see how the digital rail bounces between 800 mW and 1.2 W while the test is running. Egypt's CPU portions are pretty much single-threaded as well, as shown by the yellow and green lines above.
Another interesting case is what this looks like when browsing the web. I fired up the analyzer and loaded the AnandTech homepage followed by an article, and scrolled the page in the trace above. Chrome and "Browser" on Android now use the GPU for composition and rendering the page, and you can see the red line in the plot spike up when I'm actively panning and translating around on the page. In addition, the second CPU core only really wakes up when either loading the page and parsing HTML.
One thing we unfortunately can't measure is how much power having the baseband lit up on each different air interface (CDMA2000 1x, EV-DO, WCDMA, LTE, etc.) consumes, as the MDP MSM8960 we were sampled doesn't have cellular connectivity enabled. This is something that we understand in theory (at least for the respective WCDMA and LTE radio resource states), but remains to be empirically explored. It's unfortunate that we also can't compare to the MDP MSM8660 quite yet, but that might become possible pretty quickly.
Facebook
Twitter
RSS
86 Comments
View All Comments
k1ng617 - Tuesday, February 21, 2012 - link
Honestly, I don't trust Linpack and believe it is probably one of the most outdated android benchmarks, that doesn't represent what a person will see with realworld user experience.Can you try out Antutu & CFBench and post the scores please?
juicytuna - Tuesday, February 21, 2012 - link
Indeed. Linpack is a test of software as much as hardware, who knows what kind of optimizations they could have done to the VM to get these headline grabbing scores.GPU is distincly meh for a 2012 soc, and single threaded performance doesn't seem that impressive to me. Sunspider and Browsermark seem to be on a par with what you'd expect to see from an A9@1.5ghz.
And how much of that 'faster feel' can be attributed to NAND performance?
metafor - Wednesday, February 22, 2012 - link
There are some hickups in Android that have to do with the UI thread looking up storage but for the most part, it's a CPU thing. The thing to keep in mind is that UI fluidity is an entirely different type of code than Javascript parsing. And looking at the Basemark results, Krait is quite capable in that department.arm.svenska - Tuesday, February 21, 2012 - link
Why is the phone so long? I get that it is a reference design. But, could someone tell why it is like that?douglaswilliams - Tuesday, February 21, 2012 - link
I don't know for sure, not a definitive answer here, just adding to the discussion.Like you said, it's a reference design (Mobile Development Platform). They put as little time as possible into making this pretty.
When I was in college we had some old development platforms for some Motorola chips that were essentially a large circuit card with ports on all the sides for all the I/O and buttons to push for different operating modes like programming mode. It in no way looked like what an actual product would look like - because that wasn't its purpose.
peevee - Tuesday, February 21, 2012 - link
Out-of-order Krait core at 1.5GHz consumes only 750mW. An Atom core at the same frequency consumes as much as 10x of that! While being in-order, no faster, if not slower! What a fail for Intel!Khato - Tuesday, February 21, 2012 - link
You might consider reading Anandtech's article covering the Intel Atom Z2460 launch in January - http://www.anandtech.com/show/5365/intels-medfield...Granted, we're only given SunSpider and BrowserMark benchmarks for the Atom Z2460 reference platform, but they're both actually ahead of the numbers for the Krait MDP - 1331.5 versus 1532 on SunSpider and 116425 vs 110345 on BrowserMark. While I expected Atom to be competitive, I'd thought it likely for Krait to be slightly ahead on the single threaded benchmarks, so I'm somewhat surprised that it's not. (Note that I'm somewhat surprised that there was no mention of how Krait compares to Atom Z2460 in the article.)
As for power, that same article states that the Atom Z2460 SoC consumes ~750 mW at 1.6GHz - that's for the entire SoC, not just the CPU core. It'll be quite interesting to see how actual battery life compares between products once released.
metafor - Tuesday, February 21, 2012 - link
The difference is, one is Intel's numbers and the other is a 3rd party reviewer's on an actual device.So yes, I agree. We'll have to see what actual phones using Atom will be like. Note that Sunspider isn't the end-all of "single-threaded performance" either. The JIT for Javascript on x86 is far more mature -- having been developed for a decade now -- than it is for ARM.
Khato - Tuesday, February 21, 2012 - link
Well, I tend to trust Intel's numbers when they're actual hard numbers rather than percentages or normalized figures - they can't exactly get away with making up figures.And no question about the fact that SunSpider/Browsermark aren't indicative of all too much... but I wouldn't claim that Intel's advantages on those benchmarks are due to a superior JIT/software advantage. Remember the performance figures from that Oak Trail Tablet prototype running an early Android port from June of 2011? That was a prime example of the sort of software disadvantage that Intel had to overcome in order to get Android running well on x86. While a bit dated, here's an excellent example of the performance differences on x86 java implementations between OS (note that linux had a slightly newer version, but they were both using the latest available) - http://www.phoronix.com/scan.php?page=article&...
metafor - Tuesday, February 21, 2012 - link
No, but you'd be surprised how much a bit of pick-and-choose can help. Most comprehensive reviews are pretty rigorous with how many times they repeat a test, how much warm-up they give a device and whether or not they pick the median, average, etc.One could easily pick the best number, which can vary quite a bit especially for a JIT benchmark.
I've also seen that comparison before. There was a rather thorough discussion of it and its relative lack of merits at RWT. I'd link, but it's being marked as spam :/