The Qualcomm Snapdragon 835 Performance Preview
by Matt Humrick & Ryan Smith on March 22, 2017 4:30 AM EST- Posted in
- Smartphones
- Snapdragon
- Qualcomm
- Mobile
- SoCs
- Snapdragon 835
- Kryo
The Snapdragon 820 SoC was a significant milestone on Qualcomm’s roadmap. It was a solid improvement over the 808/810, delivering higher performance and efficiency, and became a commercial success, finding its way into the majority of flagship phones last year. More importantly, it heralded Qualcomm’s vision for mobile devices: heterogeneous computing. This meant new hardware—a much improved Hexagon 680 DSP that added single instruction, multiple data (SIMD) Hexagon Vector Extensions (HVX); Qualcomm’s first fully-custom 64-bit CPU core, Kryo, which focused on improving floating-point IPC; and an updated Adreno GPU with strong ALU performance—for enabling new software technologies and user experiences—artificial intelligence for smarter personal assistants, machine learning for object recognition, computational photography for better image and video quality, and new AR/VR experiences.
Snapdragon 835—now a part of Qualcomm’s Snapdragon Mobile Platform that includes all of the company’s mobile hardware and software—is an evolutionary product that builds on this vision. The greater than 3 billion transistor SoC is the first to use Samsung’s 10nm "10LPE" FinFET process, which reduces overall package size by 35% relative to Snapdragon 820. The new SoC’s CPU transplant and X16 LTE modem, which tops out at 1Gbps (Category 16) on the downlink, are the biggest changes, but most of the other blocks within the SoC have received at least minor updates too. For detailed information about all the changes and new features, you can read our Snapdragon 835 launch article.
| Qualcomm Snapdragon SoCs: Three Generations | |||
| SoC | Snapdragon 835 (MSM8998) |
Snapdragon 820 / 821 (MSM8996 / MSM8996 Pro) |
Snapdragon 810 (MSM8994) |
| CPU | 4x Kryo 280 Performance @ 2.45GHz 4x Kryo 280 Efficiency @ 1.90GHz |
2x Kryo @ 2.15GHz / 2.34GHz 2x Kryo @ 1.59GHz / 2.19GHz |
4x Cortex-A57 @ 2.00GHz 4x Cortex-A53 @ 1.50GHz |
| GPU | Adreno 540 @ 710MHz ? | Adreno 530 @ 624MHz / 653MHz | Adreno 430 @ 630MHz |
| Memory | 2x 32-bit @ 1866MHz LPDDR4x 29.9GB/s |
2x 32-bit @ 1866MHz LPDDR4 29.9GB/s |
2x 32-bit @ 1600MHz LPDDR4 25.6GB/s |
| ISP/Camera | Dual 14-bit Spectra 180 ISP 1x 32MP or 2x 16MP |
Dual 14-bit Spectra ISP 1x 25MP or 2x 13MP |
Dual 14-bit ISP 1x 21MP |
| Encode/Decode | 2160p30 (2160p60 decode), 1080p120 H.264 & H.265 |
2160p30 (2160p60 decode), 1080p120 H.264 & H.265 |
2160p30 (2160p60 decode), 1080p120 H.264 & H.265 |
| Integrated Modem | Snapdragon X16 LTE (Category 16/13) DL = 1000Mbps 3x20MHz CA, 256-QAM UL = 150Mbps 2x20MHz CA, 64-QAM |
Snapdragon X12 LTE (Category 12/13) DL = 600Mbps 3x20MHz CA, 256-QAM UL = 150Mbps 2x20MHz CA, 64-QAM |
Snapdragon X10 LTE (Category 9) DL = 450Mbps 3x20MHz CA, 64-QAM UL = 50Mbps 1x20MHz CA, 16-QAM |
| Mfc. Process | 10nm LPE | 14nm LPP | 20nm SoC |
In what has become an annual tradition going all the way back to Snapdragon 800, Qualcomm invited the media to its headquarters in San Diego for some feature demonstrations and limited testing using the company's Mobile Development Platform (MDP) devices. These are fully functional tablets or smartphones in a slightly oversized, utilitarian chassis used for hardware testing and software development. The MDP for Snapdragon 810 took the form of a tablet, while Snapdragon 820 came inside a large smartphone with a 6.2-inch display. This downsizing trend continues for Snapdragon 835, whose MDP/S is a smartphone with 6GB of RAM, a 5.5-inch 2560x1440 display, and a small 2850 mAh battery. The use of a smaller chassis is encouraging, because it has less mass and surface area to absorb and dissipate heat. This suggests a lower TDP for the 835, but we'll need to measure power consumption to be sure.
Because we only had a limited time for testing, we focused on running some basic CPU, GPU, and memory performance tests. Keep in mind that we were testing prototype hardware running pre-production software that resulted in a few hiccups. The condensed testing period also forced us to stray slightly from our usual testing methodology. Therefore, these numbers should be viewed as preliminary and could change by the time retail units begin shipping.
Facebook
Twitter
RSS
128 Comments
View All Comments
Drumsticks - Wednesday, March 22, 2017 - link
On iOS or Windows, sure. Android has widely different design parameters.Instead of just dismissing a 16 page analysis off hand, you should give it a read.
http://www.anandtech.com/show/9518/the-mobile-cpu-...
Single threaded performance is King on iOS and windows. Android seems to very much prefer having access to many threads in a lot of use cases.
AnandTechReader2017 - Friday, April 21, 2017 - link
Completely disagree for the Android OS.A nice thing Android does, if you'd like to try a simple java application, is that it automatically optimizes applications to use multiple threads even if you as a developer don't design it to do so. I noticed this the other day as I was building a quick prototype for a network application, whereby I just wanted to test it out, it never hit above 20% on each core (Android has a nice feature under Developer > Show CPU usage) even though the app should have frozen while waiting for the network thread to complete. Lovely libraries provided definitely have an impact on it and CPU developers take advantage of that fact when they create a CPU for an Android system, same thing that Apple does when it focuses on single-thread performance.
MrSpadge - Wednesday, March 22, 2017 - link
They showed the Android browser using many threads. What was missing from my POV was the performance gain from these additional threads. One can assume Google woudln't do it like that if it wasn't worth, but I'd prefer measurements.lefty2 - Wednesday, March 22, 2017 - link
Browser use many threads to stop i/o requests from blocking the main thread, but those i/o are not doing any work, just waiting for the request to return from the server.melgross - Wednesday, March 22, 2017 - link
No, what they found was that battery life wasn't effected. Sometimes using all cores gave a small boost to performance, and sometime it degraded performance. It's mostly marketing hype. The more the better.Gasaraki88 - Wednesday, March 22, 2017 - link
This so wrong... Phone apps are almost all multi threaded.tuxRoller - Wednesday, March 22, 2017 - link
^|
That person knows what they are talking about.
tuxRoller - Wednesday, March 22, 2017 - link
"most smartphone apps don't use multiple threads"Please show me the data backing up that statement.
melgross - Wednesday, March 22, 2017 - link
Multicore performance isn't real world on phones, and likely on tablets as well. Very few apps, almost none of them in fact, support more than two cores. Even when multitasking, something that isn't done on phones the way it might be on desktops, doesn't benefit terribly with more cores. And the legitimacy of using all big/little cores at once is even worse.Maybe, someday that will change, but not yet.
BurntMyBacon - Thursday, March 23, 2017 - link
I do think multicore performance is more important than you seem to believe, but as I said above, single core performance is also important. It is generally more important than multicore performance, but not so much that I can just dismiss multicore performance. The A10 still does well in most multithreaded use cases despite the lower number of cores.I've never been a fan of big.LITTLE anyways (particularly with the large clusters). It seems like the wrong way to handle the efficiency issue to me. Without going into a long discussion, I'll point out that the A9 (and predecessors) and Intel's lineup do just fine without it. If Android could assign tasks to individual cores based on need rather than swapping entire clusters in and out, then there may be some benefit to keeping background processes on low power cores to improve battery life and responsiveness of foreground applications, but you still wouldn't need a 4+4 configuration. In any case, that's a discussion for another time.