System Performance - Slightly Underwhelming?

While synthetic steady state workloads are one thing, real-world workloads are more transactional and their performance is determined not just by hardware, but as well by software. Here things like the CPU scheduler and OS APIs can have a big effect on the resulting perceived performance of a device.

PCMark Work 2.0 - Web Browsing 2.0

Starting off with PCMark’s Web Browsing 2.0 test, the Snapdragon 855 goes off to a bad start. Here for some reason the S855 QRD wasn’t able to distinguish itself from the lower end of Snapdragon 845 devices – here we had expected the phone to perform and compete similarly to the Kirin 980 in the Mate 20’s.

PCMark Work 2.0 - Video Editing

The video editing score is again also quite mediocre, but again the reason for this is that this test has largely reached a performance plateau where most of today’s devices no longer really showcase meaningful differences between each other.

PCMark Work 2.0 - Writing 2.0

The writing sub-test is among one of the most important in PCMark, and luckily here the Snapdragon 855 QRD performed as expected as it’s within range of the Mate 20’s.

PCMark Work 2.0 - Photo Editing 2.0

The photo editing sub-test is characterised by shorter heavy RenderScript workload bursts. The QRD performs well, although it’s within the results of the top Snapdragon 845 devices.

PCMark Work 2.0 - Data Manipulation

Finally in the data manipulation result which is more single-thread bound, we see the Snapdragon 855 perform well, but still remains neck-and-neck with the Kirin 980 devices as well as behind the Pixel 3’s very aggressive scheduler implementation.

PCMark Work 2.0 - Performance

Overall, the Snapdragon 855 QRD in PCMark ended up among the top scorers, however I found the result to be a bit disappointing as it doesn’t appear to achieve a higher ranking than the Pixel 3, and Huawei’s Kirin 980 Mate 20’s are also ahead.

Speedometer 2.0 - OS WebViewWebXPRT 3 - OS WebView

I’ve discussed the results with Qualcomm, and they were surprised to see the numbers end up like this. They stated that it’s something they will look into, and stated that it’s possible that the scheduler and software stack on commercial devices might improve performance. Something to be revisited once we get our hands on the first phones.

The web-based benchmarks such as Speedometer 2.0 and WebXPRT 3 showcase similar relatively muted results. Here I had expected Qualcomm to perform really well given the scheduler performance showcase of the Snapdragon 845. The results of the Snapdragon 855 are quite meagre, especially in a steady-state throughput workload such as Speedometer 2.0. Here the Snapdragon 855 only manages to showcase a ~17% improvement over the last generation, and also lags behind the Kirin 980 by some notable amount.

Performance Scaling Ramp Test

One of the newer kind of tests I introduced last year and has used in our review of the Apple iPhone XS is the scaling ramp test – here showcasing the improved DVFS responsivity of iOS12 across several generations of iPhones.

I’ve quickly ran this on the S855 QRD to be able to get a sense of the scheduler and DVFS mechanism:

Here we see the Snapdragon 855 QRD being able to scale from a sleeping idle workload state to its maximum performance state in around 100ms. To compare this, I also showcase the scaling behaviour of the S845 in both the S9+ as well as the Pixel 3. The difference between the Pixel 3’s aggressive boost behaviour and the S9’s more step-wise frequency scaling showcases the best visual representation of the perceived responsiveness difference between the two devices.

The Snapdragon 855 here falls somewhere in-between both. It’s to be noted that the workload does get boosted to an “efficient” big core at 2.45GHz in around 40ms which is a very fast scaling behaviour.


Comparing the Snapdragon 855 against the Kirin 980, we see that the Snapdragon isn’t any slower in reaching the maximum performance states. What is odd in these results is that the workload sees a significant pause of ~2.4ms when migrating over from the little cores, something that seems to affect only devices with Qualcomm’s custom scheduler. It’s an interesting find that I’ll have to investigate more.

Overall, real-world performance of the Snapdragon 855 is a bit lower than I had expected it to be. I’m not exactly sure what the cause here is; on the scheduler side we’ve verified that the workload doesn’t inherently scale slower than the Kirin 980. The only other explanation I could see is that we might be seeing some disadvantage of the smaller L3 cache or even the higher DRAM latency.

As we’ve seen in past Snapdragon performance previews, final commercial device performance is subject to change, and it’s possible the performance situation will be more tuned in actual shipping phones.


Inference Performance: Good, But Missing Tensor APIs GPU Performance - Returning To Lower Power
Comments Locked


View All Comments

  • cknobman - Tuesday, January 15, 2019 - link

    So better power consumption but performance wise it looks like a swing and a miss.
    Nothing too meaningful over the 845.
  • IGTrading - Tuesday, January 15, 2019 - link

    To be honest, this is good enough for me and most of us.

    I'd be happy to see Qualcomm focusing more on server CPUs and computers/notebook running Windows on AMR chips.

    It's been something like 15 or even 20 years since coders/developers stopped worrying about optimizations, performance improvements and now they only rely on the much improvement hardware being available year after year.

    We were building optimized web pages 20 years ago, that looked good and loaded in less than 10 seconds on a 5,6 KB connection.

    Now idiots build sites where the Home Page is 300 MB heavy and complain about mobile CPUs and mobile networks not being fast enough.
  • bji - Tuesday, January 15, 2019 - link

    "t's been something like 15 or even 20 years since coders/developers stopped worrying about optimizations, performance improvements and now they only rely on the much improvement hardware being available year after year."

    Speaking as a software developer, I will say that your statement is bullshit. I have yet to work on any product where performance wasn't considered and efforts to improve efficiency and performance weren't made.
  • bji - Tuesday, January 15, 2019 - link

    Also everything your browser does now is 10,000 times more complicated than anything that browsers did 20 years ago. All of the effort that has gone into developing these technologies didn't go nowhere. You are just making false equivalencies.

    And if a page took 5 seconds to load in 2019, let alone 10 seconds, you'd be screaming about how terrible the experience is.
  • name99 - Tuesday, January 15, 2019 - link

    It's usually the case that people talking confidently about what computers were like 20 yrs ago (especially how they were faster than today...) are in the age range from not yet born to barely five years old at the relevant time.

    Those of us who lived through those years (and better yet, who still own machines from those years) have a rather more realistic view.
  • rrinker - Wednesday, January 16, 2019 - link

    Really? What's the 'realistic' view? For background, the first computer I had regular access to was a TRS-80 Model 1 when they first came out in 1977, so I've been doing this a LONG time. Software today is a bloated mess. It's not all the programmers' fault though, there is this pressing need for more and more features in each new version - features that you're lucky if 1% of the users actually even utilize. Web pages now auto start videos on load and also link a dozen ads from sites with questionable response times. That would have been unthinkable in the days 56k and slower dialup, and it just wasn't done. I even optimized my BBS in college - on campus we had (for the time) blazing fast 19.2k connections between all dorm rooms and the computing center, at a time when most people were lucky to have a 1200bps modem, and the really lucky ones had the new 2400s. So I set up my animated ANSI graphic signons in a way that on campus users at 19.2k would get the full experience and off campus users, connecting via the bank of 1200 baud modems we had, would get a simple plain text login. In today's world, there is a much grater speed disparity in internet connections. I have no problem with pretty much any site - but I have over 250mbps download on my home connection. Go visit family across the state - the best they can get a a DSL connection that nets about 500k on a good day on a speed test - and so many sites fail to load, or only ever partially load. But there are plenty of sites that don;t try to force graphics and videos down your throat that still work fine.
    No, things weren't faster back in the day - but because the resources were more limited, both for apps running on the local computer in terms of RAM, storage, and video performance as well as external connectivity, programs had to be more efficient. Heck, the first computer I actually owned had a whole 256 bytes of RAM - to do anything I had to be VERY efficient.
  • Klinky1984 - Friday, January 18, 2019 - link

    So pay per minute slow internet, the non-standard compliance of Netscape 2.0 and IE 3.0, an internet without any video streaming, were there "good ol days"? Sorry but I remember bloated pages that took a minute plus to download or never loaded. I remember waiting 3 minutes for one single high res jpeg to download... They were not glory days. Can your 256 byte computer even handle Unicode? No way.
  • seamadan - Tuesday, January 22, 2019 - link

    I bet your pages looked REALLY good. Like REALLY REALLY good. I'm in awe and I haven't even seen them
  • Krysto - Tuesday, January 15, 2019 - link

    That bold has sailed. They've already given all the server IP on a silver platter to their forced Chinese "partner".

    That said, Snapdragon 8cx for notebooks does look quite intriguing, mainly because of its 10MB shared cache.
  • Krysto - Tuesday, January 15, 2019 - link


Log in

Don't have an account? Sign up now