CPU Performance & Efficiency: SPEC2006

We move on with our analysis by using SPEC2006 on the Snapdragon 855 QRD. SPEC2006 is an important benchmark as not only does it represent a tool that is used by many companies to architect their CPU designs, but it also a very well understood and academically documented workloads that can serve as a macro-benchmark to determine microarchitectural aspects of a CPU and system.

It’s to be noted that SPEC2006 has been deprecated in favour of SPEC2017, and although we’ll switch to that at some point, for mobile platforms SPEC2006 still represents a good benchmark. Because our scores aren’t official submissions, as per SPEC guidelines we have to declare them as internal estimates from our part.

A Big Note on Power on the QRD

Although for this article I was able to collect power figures for both CPU and GPU workloads, the figures are not of an as high certitude as when measured on commercial devices. The reason for this is that much like last year’s Snapdragon 845 QRD, this year’s 855 platform reports rather high idle power in the 950-1050mW range, about 500mW more than one would expect in a final product. Because our power measurement methodology represents publishing active system power, meaning we measure total power during a given workload and subtract the idle power under the same conditions, there is a degree of uncertainty if the idle power by default is quite high.

Today’s power efficiency figures thus merely represent a guideline – and we’ll make sure to re-test the results once we get our hands on final commercial devices.

The Results – The Snapdragon 855 Performs Admirably

We’ll start off with the aggregate results and drill down in the detailed results later:

The Snapdragon 855 ends up performing extremely well, ending up neck-and-neck with the Kirin 980’s performance, which shouldn’t come as too big of a surprise.

In SPECint2006, the Snapdragon 855 performs 51% better than the Snapdragon 845, all while improving power efficiency by 39% over its predecessor. Against the Kirin 980 which is currently its nearest Android competitor, the Snapdragon just slightly edges ahead by 4%.

In SPECfp2006, the Snapdragon 855 shows an even bigger 61% leap over the Snapdragon 845, and also manages to better showcase the 9% clock speed advantage over the Kirin 980, sporting a similar performance lead.

Again what is most important in these results is the power efficiency figures. One of the things that had me worried during Qualcomm’s Snapdragon 855 launch in Hawaii last month is that the company pretty much avoided talking or publishing any meaningful power efficiency claims on the side of the CPU. Fortunately it seems there wasn’t any need to be concerned as the Snapdragon 855, at first glance, seems to be extremely efficient even on the high clocked 2.85GHz Prime core.

Detailed Results

Drilling down into the detailed results, the one comparison that is most interesting is the performance of the Snapdragon 855 against the Kirin 980. On one hand the Snapdragon 855 is clocked 9% higher as well as promises some tuned microarchitectural characteristics which promise to improve IPC – while on the other hand HiSilicon’s implementation is more straightforward and brings with itself a bigger L3 cache as well as memory latency advantages.

In the vast majority of workloads, both chipsets are neck-and-neck, only diverging in some key aspects. In less memory hierarchy demanding workloads, the Snapdragon more easily is able to showcase its clock speed advantage. In more latency sensitive workloads, this difference shrinks or reverses. 462.libquantum is an interesting result as Qualcomm commented that its lead here is primarily due to the customisations made on the CPU core – although they wouldn’t exactly specify which aspect in particular is bringing the boost.

The biggest performance discrepancy on the negative side of things is the 13% disadvantage in 458.sjeng – the benchmark is most sensitive to branch mispredictions and again here Qualcomm has stated they’ve made changes to the branch data structures of the core.

What is most odd for me to see as a result, is the fact that 429.mcf performs admirably well on the Snapdragon 855 – which goes against intuition given the platform’s memory latency disadvantage. It is possible here that the Snapdragon 855 performs better than the Kirin 980 due to its better L3 cache latency?

On the SPECfp2006 results, the results can be very clearly categorised into two sets: In one set the Snapdragon 855 clearly showcases a healthy advantage over the Kirin 980, up to very notable 17% and 22% leads in 447.dealII and 453.povray. In the other set, the Snapdragon is again neck-and-neck with the Kirin 980, and these happen to again be the workloads that are most memory sensitive in the FP suite.

Overall, the Snapdragon 855’s CPU performance does not disappoint. Performance on average is ahead of the Kirin 980, although not by much. Here both chipsets are most of the time neck-and-neck, and it will mostly depend on the workload which of the two will take the lead.

More important than performance, the efficiency of the Snapdragon 855 is top-notch, exceeding what I had expected from the higher clock implementation of the chip. There is still a degree of uncertainty over the power numbers on the QRD platform, but if these figures are representative of commercial devices, then 2019’s flagship will see excellent battery life.

Introduction & Specifications Inference Performance: Good, But Missing Tensor APIs
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