CPU and System Performance

Snapdragon 820 included Qualcomm’s first fully-custom 64-bit CPU cores. The unique microarchitecture’s floating-point IPC was very good, but integer IPC was no better than ARM’s older A57 core. Its power efficiency was lower than competing cores as well. Instead of using a revised quad-core Kryo arrangement for Snapdragon 835, Qualcomm decided to go in a completely different direction.

The new Kryo 280, despite the similar name, shares no design DNA with the original Kryo. Its an octa-core, big.LITTLE configuration with four “performance” cores and four lower-power “efficiency” cores. What makes Kryo 280 unique, however, is that it’s the first design to use ARM’s new "Built on ARM Cortex Technology" (BoC) license, which allows vendors to customize ARM cores. This new semi-custom option gives vendors the ability to differentiate their products from those using ARM’s stock cores while avoiding the more costly route of creating a fully-custom design from scratch.

The BoC license allows the vendor to request certain modifications, particularly to the fetch block and issue queues, but certain parts of the microarchitecture are off limits, including the decoder and execution pipelines, because modifying these blocks requires too much effort. Qualcomm is not disclosing which ARM cores serve as the foundation for Kryo 280 or precisely which modifications it requested, but it did say that both CPU clusters use semi-custom cores. Qualcomm also confirmed that Snapdragon 835’s memory controllers are its own design.

Geekbench 4 - Integer Performance
Single Threaded
  Snapdragon 835 Snapdragon 821
(% Advantage)
Snapdragon 810
(% Advantage)
AES 905.40 MB/s 559.10 MB/s
714.47 MB/s
LZMA 3.13 MB/s 2.20 MB/s
1.92 MB/s
JPEG 16.80 Mpixels/s 21.60 Mpixels/s
12.27 Mpixels/s
Canny 23.60 Mpixels/s 30.27 Mpixels/s
23.63 Mpixels/s
Lua 1.84 MB/s 1.47 MB/s
1.20 MB/s
Dijkstra 1.73 MTE/s 1.39 MTE/s
0.91 MTE/s
SQLite 53.00 Krows/s 36.67 Krows/s
33.30 Krows/s
HTML5 Parse 8.67 MB/s 7.61 MB/s
6.38 MB/s
HTML5 DOM 2.26 Melems/s 0.37 Melems/s
1.26 Melems/s
Histogram Equalization 52.90 Mpixels/s 51.17 Mpixels/s
53.60 Mpixels/s
PDF Rendering 50.90 Mpixels/s 52.97 Mpixels/s
43.70 Mpixels/s
LLVM 196.80 functions/s 113.53 functions/s
108.87 functions/s
Camera 5.71 images/s 7.19 images/s
4.69 images/s

The Snapdragon 835’s Kryo 280 CPU shows a noticeable improvement in integer IPC relative to the 820/821’s Kryo core. This is not unexpected, however, considering integer performance was not one of Kryo’s strengths. While most workloads see large increases, there are a few regressions too, notably in JPEG, Canny, and Camera. We saw this same performance pattern from Kirin 960’s A73 CPU as well. These integer results, along with L1/L2 cache behavior, match the A73’s unique performance fingerprint, confirming that Kryo 280’s performance cores are based on ARM’s latest IP.

Quickly comparing Snapdragon 835 and Kirin 960 Geekbench 4 Integer results also shows performance variations that cannot be fully explained by differences in frequency or normal testing variance. The differences only occur in a few specific tests and range from 9% to -5%, which again is not completely unexpected given the limited number of modifications the BoC license allows for semi-custom designs.

Geekbench 4 (Single Threaded) Integer Score/MHz

The chart above divides the overall integer score by CPU frequency, making it easier to directly compare IPC. Taken as a whole, the performance of Kryo 280’s semi-custom performance core is not much different than the Kirin 960’s A73 core in this group of workloads, with individual gains and losses nearly averaging out. Its overall IPC is also only about 6% higher than A72 and 14% higher than A57. Its advantage over Snapdragon 820/821 widens to 22%, partly because Kryo’s poor performance in the LLVM and HTML5 DOM workloads drags down its overall score.

While Snapdragon 835 leads other SoCs by a slim margin in this test, it’s not a sweeping victory. Just like we saw with Kirin 960’s A73 cores, performance improves in some workloads but regresses in others.

Geekbench 4 - Floating Point Performance
Single Threaded
  Snapdragon 835 Snapdragon 821
(% Advantage)
Snapdragon 810
(% Advantage)
N-Body Physics 879.6 Kpairs/s 1156.7 Kpairs/s
580.2 Kpairs/s
Rigid Body Physics 6181.7 FPS 7171.3 FPS
4183.4 FPS
Ray Tracing 232.6 Kpixels/s 298.7 Kpixels/s
130.1 Kpixels/s
HDR 7.8 Mpixels/s 10.8 Mpixels/s
6.4 Mpixels/s
Gaussian Blur 23.4 Mpixels/s 48.5 Mpixels/s
21.9 Mpixels/s
Speech Recognition 13.9 Words/s 10.9 Words/s
8.1 Words/s
Face Detection 513.8 Ksubs/s 685.0 Ksubs/s
404.4 Ksubs/s

Snapdragon 835’s Kryo 280 takes two steps backwards when running Geekbench 4’s floating-point workloads, finishing well behind Snapdragon 820/821’s Kryo core and even a little behind SoCs using the A72 core. Its IPC is on par with the Kirin 960’s A73 core, with even less variation between individual scores than we saw when running the integer workloads.

The A73’s slight performance regression relative to the A72, which also applies to the semi-custom Kryo 280, is a bit surprising, because their NEON execution units are relatively unchanged from the A72’s design. If anything, the A73’s lower-latency front end and improvements to its fetch block and memory system should give it an advantage, but that’s not the case. The A73’s narrower decode stage could limit performance for some workloads but not all. Both the Kirin 960’s A73 and Snapdragon 835’s Kryo 280 show reduced L2 cache read/write bandwidth (and lower L1 write bandwidth) relative to A72, which could also negatively impact performance.

Geekbench 4 (Single Threaded) Floating Point Score/MHz

Snapdragon 835’s floating-point IPC is 23% lower than Snapdragon 820/821’s. One has to wonder if this is the result of a forced compromise or a willing change in design philosophy. When Qualcomm started work on Kryo more than 2 years ago, it may have envisioned new workloads that never materialized. Or it could be that with more compute workloads shifting to the GPU and DSP to improve efficiency, it was willing to sacrifice some floating-point performance to save area and power.

Geekbench 4 - Memory Performance
Single Threaded
  Snapdragon 835 Snapdragon 821
(% Advantage)
Snapdragon 810
(% Advantage)
Memory Copy 4.70 GB/s 7.82 GB/s
3.99 GB/s
Memory Latency 13.95 Mops/s 6.64 Mops/s
4.29 Mops/s
Memory Bandwidth 17.95 GB/s 13.53 GB/s
7.15 GB/s

The Kryo 280, A73, A72, and A57 cores all have 2 address generation units (AGUs). Unlike the A72/A57, however, which use dedicated AGUs for load and store operations, each AGU in Kryo 280/A73 is capable of performing both operations. For Kirin 960, this change, among others, reduces memory latency and significantly improves bandwidth to main system memory relative to Kirin 950.

Snapdragon 835’s memory latency and bandwidth numbers are even better than Kirin 960’s—up to 11% after accounting for differences in CPU frequency. The 835 sees impressive gains over the 820/821 too. Switching to Kryo 280 does not provide the same bandwidth boost as the switch to A73 did for Kirin 960, however, because Kryo’s 2 AGUs were already capable of performing both load and store operations, albeit with a higher latency in some cases.

System Performance

So far our initial results show Snapdragon 835’s Kryo 280 is a big.LITTLE combination of semi-custom A53 and A73 CPU cores, whose integer and floating-point IPC is similar to Kirin 960. System-level tests like PCMark, which includes several realistic workloads that stress the CPU, GPU, RAM, and NAND storage using standard Android API calls, are affected by more than just CPU IPC and memory latency, however. Device OEMs tune the software parameters that control the scheduler and DVFS systems to achieve the desired balance between performance and battery life, to meet quality of service goals, and to stay within a particular design's thermal limits.

No doubt we'll see performance vary among the upcoming Snapdragon 835 devices, just like we do with other SoCs, but for now we see Qualcomm’s 835 MDP/S with the top overall score in PCMark, just barely ahead of the Mate 9 and its Kirin 960 SoC. It’s also 23% faster overall than the top-performing Snapdragon 821 phone.

PCMark - Work 2.0 Performance Overall

PCMark - Web Browsing 2.0

PCMark - Writing 2.0

PCMark - Data Manipulation 2.0

The Snapdragon 835 MDP/S performs well in the Web test, although its advantage over the Mate 9 is only 10%. Its performance lead over the Snapdragon 820/821 phones, which all fall behind SoCs using ARM’s A72 and A73 CPUs, grows to 34% in this integer-heavy test.

The PCMark Writing test generates frequent, short bursts of activity on the big CPU cores while performing a variety of operations, including PDF processing and file encryption (both integer workloads), memory operations, and even reading and writing some files to internal NAND. Because of this, it tends to produce the most varied results. Take the spread between the Snapdragon 820/821 phones, for example, where the LeEco Le Pro3 is 40% faster than the Galaxy S7 edge. The performance difference between the Snapdragon 835 MDP/S and Mate 9 is negligible, however. Comparing Snapdragon 835 to older members of the Snapdragon family reveals more significant differences; it’s 24% faster than the LeEco Le Pro3 (S821), 80% faster than the Nexus 6P (S810), and 162% faster than the Lenovo ZUK Z1 (S801AC).

The PCMark Data Manipulation test is another primarily integer workload that measures how long it takes to parse chunks of data from several different file types and then records the frame rate while interacting with dynamic charts. Once again the Snapdragon 835 MDP/S and Mate 9 deliver similar performance, but they separate themselves a little further from the pack. Like we saw in the Writing test, the phones using Snapdragon 820 show significant performance variation, providing another example of how OEM tinkering impacts the user experience. The Snapdragon 835 MDP/S outperforms the Pixel XL by 28% and the LG G5 by 111%.

PCMark - Video Editing 2.0

PCMark - Photo Editing 2.0

The Video Editing test, which uses OpenGL ES 2.0 fragment shaders for applying video effects, actually presents a very light load to the system. After monitoring the behavior of several phones while running this test, I’ve noticed that GPU frequency remains close to idle and most phones do not migrate threads to the big CPU cluster, using the little A53 cluster exclusively, which is why we see very little performance variation in this test.

The Photo Editing test applies a number of different photo effects and filters with both the CPU and GPU. The Snapdragon 835 MDP/S and the phones using Snapdragon 820/821 rise to the top of the chart thanks to their Adreno GPU’s strong ALU performance. The 835’s Adreno 540 GPU helps it perform 33% better than the highest performing phone with an ARM GPU, the Mate 9 and its Mali-G71.

Kraken 1.1 (Chrome/Safari/IE)

WebXPRT 2015 (Chrome/Safari/IE)

JetStream 1.1 (Chrome/Safari)

Yes, the iPhones perform well in these JavaScript tests. No, you cannot use these tests to compare IPC between Apple’s A-series SoCs and those found in Android phones, because they are running different browsers. A significant portion of the iPhones’ performance advantage actually comes from Safari’s JavaScript engine.

The Snapdragon 835 MDP/S compares favorably to other phones using the Chrome browser (all of the phones are using the latest version). It joins the Snapdragon 820/821 phones at the top of the chart in Kraken, although, its performance is no different. It essentially matches the Mate 9 in JetStream too, but pulls ahead of the Snapdragon 820/821 phones by 15% to 37%. Performance is unexpectedly good in WebXPRT 2015 where it pulls ahead of the Mate 9 by 24% and up to 67% over the Galaxy S7 (S820).

As an additional point of interest, and to further highlight the software layer’s effects, we also ran these tests using Qualcomm’s internally developed browser that’s optimized for Snapdragon SoCs. Kraken only sees a modest improvement to 2,305 ms, but JetStream improves by 24% to 87 and WebXPRT 2015 jumps to 280, an 82% improvement.

Introduction GPU Performance
Comments Locked


View All Comments

  • zeeBomb - Wednesday, March 22, 2017 - link

    Its that time of year again!
  • name99 - Wednesday, March 22, 2017 - link

    "The [3DMark] Physics test runs on the CPU and is heavily influenced by how well an SoC’s memory controllers handle random access patterns. "

    No it isn't, at least not to an extent that matters in any modern CPU. Why do you keep posting this rubbish in review after review?

    The source code is available for examination. It basically tests (frequency)*(number of cores) and is useless for learning anything beyond that. That's why it's always the only test in which Apple looks bad --- because Apple's running two cores as opposed to 4/6/8/10 on Android, and, at least in the past, those cores were under-clocked relative to the Android cores.

    If people want to post the 3DMark Physics numbers, whatever, I don't care. But I do think doing so is a waste of reviewers' and readers' time --- there is simply no useful additional information provided by that benchmark.
    The fact that 3DMark continues to push it (as opposed to the way GeekBench every year or two tries to respond to complaints and concerns about its benchmarks) tell you something about the relative professionalism of the two companies.
  • Matt Humrick - Wednesday, March 22, 2017 - link

    "It basically tests (frequency)*(number of cores)"

    Both of these are factors, but it's not the whole story according to the developer I spoke with at Futuremark. If you have additional information to prove your claim, please share it with me via email. My mind is always open :)
  • name99 - Thursday, March 23, 2017 - link

    I looked into this in detail years ago when there was a big kerfuffle about the iPhone 5S score.
    I'm not interested in spending another day doing the exact same thing. I'll just point out that what I am saying matches the data.
    Sure, I'm not saying that THE ONLY THING is (frequency)*(number of cores), there's some small 5 to 10% variation around that; but that variation is unimportant --- the big picture is embedded in what I said.

    Now, does this mean it's a good benchmark? Well, how much code that people care about is multi-threaded (on Android and otherwise)?
    I'm not interested in relitigating that (given what I consider to be the astonishing incompetence and ignorance we saw on Anandtech the last time this was discussed, with a VAST proportion of readers apparently unaware of such concepts as timesharing, or how to accurately calculate the thread level parallelism of an executing piece of code).
    I will say that the most recent academic papers I've read, dated 2016, referring to work in around 2014, show that it's higher than you might expect, not as high as you might hope. Across a very wide range of Android apps the thread level parallelism is slightly larger than 2, showing, basically (in my interpretation)
    - an Android controlled thread doing misc stuff that's pretty busy
    - a main app thread
    - various small completion routines, async routines, and interrupts
    So basically two cores get you almost all the value in real world core, a third core occasionally picks up a small amount of extra available work.

    Now read what I am saying before getting upset. I'm NOT saying that ARM is stupid to ship 4 (performance) cores. ARM cores are tiny, they can be of (very occasional) value to a few talented developers today, and the only way we'll EVER get the mass market to code more parallel is to have the hardware out there as the default. So I'm happy that ARM is flooding the world with hexacore, octacore, decacore chips. (And I think Apple is being penny-wise and pound-foolish by not making every SoC they ship a triple core ala A8X --- the extra area would be small, and it would likewise provide an incentive for developers to get off their asses.)

    But that's a different argument from whether core-count provides "visible performance" today.
    I think the answer to that is clearly no. The first thing that matters to most users is snappiness (which depends, primarily, on flash performance, GPU [and the quality of the graphics code], performance governor (so does the CPU "start off" fast or "start off" slow and only get fast after .2 seconds of UI interaction? Then there are a few places where overall "endurance" performance matters (like much browser stuff, or viewing complicated PDFs --- both of which are very poorly threaded even as of 2017). Finally the cases where all cores all the time matters, and almost nothing else (the sort of thing 3DMark Physics is testing) are REALLY few and far between.

    Or to put it another way. Most CPU microarchitecture improvement since 2000 has been about discovering and exploiting the stochastic structure of REAL-WORLD computation. There are re-uses and patterns in branching, in memory access, in instruction execution that are exploited ever more aggressively in branch prediction, in cache insertion and liveness tracking, in prefetching, in loop buffers, etc. A benchmark that prides itself on randomness and in providing no way for all those smarts to add value is saying SOMETHING about the worst case performance of a CPU, but it's not clear that that something is of any value to almost everyone.
  • Frenetic Pony - Wednesday, March 22, 2017 - link

    How disappointing that yet another of the very few custom CPU designers is now gone. Looking at the general performance of the CPU now, I see no reason whatsoever to choose Qualcomm over some other, generic ARM hawker that's probably cheaper. They could at least stop pretending and just become a module seller, selling their GPU/modems/etc. separately as there doesn't seem to be any reason to choose a Qualcomm SOC as a whole.

    Other than ditching their stock (if you haven't already) none of this looks good for Qualcomm. Or for ARM for that matter, the A73 doesn't offer any performance boost over the A72 and is still trounced by Apple. Maybe the rumors of Google building its own CPU will come true and we'll see it in the Pixel 2.
  • serendip - Wednesday, March 22, 2017 - link

    No reason? They're one of the few developer and open source friendly chip manufacturers around, even if that relationship ventures into frenemy territory once in a while. Qualcomm modems and imaging blocks are pretty good too.

    Intel are developer friendly but their GPUs can be an abomination to work with. They've also effectively abandoned the mobile space. Mediatek, Huawei and Samsung either give a cold shoulder or a middle finger to devs.
  • StrangerGuy - Thursday, March 23, 2017 - link

    They dropped their own custom cores because why even bother when vanilla ARM does a better job while being cheaper...Plus the economics for a non-Apple, non-Samsung bleeding edge SoC no longer makes much sense, and 99.99% of the population buying these phones doesn't and won't give a shit to the SoC or the benchmarks.
  • Meteor2 - Thursday, March 23, 2017 - link

    It wouldn't surprise me if Qualcomm had multiple core design teams competing with each other. We've seen ARM cores come before; maybe full-custom will come back next year.
  • SyukriLajin - Thursday, March 30, 2017 - link

    I think they are just shifting their focus. The fact that they "rebranded" the snapdragon as a platform instead of just processor is one indicator. SOC is more than just cpu cores and they want people to know that. My guess is, they think that investing more money to develop a more unique platform is more important than spending valuable time and money on redoing the cpu core, ARM already invested a tons of money to develop it, no reason to reinvent the wheel when you can use the resources to provide a platform that will help them be more different then the others. I think it's wise for them. The resources would better off be spent to create a better DSP, modem, GPU etc, which will give them more return than a custom cpu core.
  • MrPhilo - Wednesday, March 22, 2017 - link

    So the Exynos 8895 GPU should in theory be faster than the 540 by quite a bit? Since the Huawei 9 uses 8, whereas Exynos uses 20, but of course with a lower clockspeed. I can see it being at least 20-30% faster than the 540.

Log in

Don't have an account? Sign up now