CPU Battle - SPEC Performance & Efficiency

We move onto SPEC for synthetic performance of the CPU cores and analysis. The following results are not officially submitted scores and therefore we must put out the disclaimer that these are estimates. The compiler used is Clang/LLVM bundled with the NDRr16rc1 and we’re using the same build we ran in the Kirin 970 article earlier in January. This includes the simple compiler flags of –Ofast and –mcpu=Cortex-A53.

The metrics measured are the SPECspeed for each workload and platform depicted on the right axis growing from the right. Bigger values represent higher performance.

I made a slight change in representation of energy efficiency compared to the Kirin 970 article, instead of the arbitrary Perf/Energy metric of SPECspeed per total Joules, this time around I’m rather representing the total energy consumed for each workload. The workloads are fixed in their complexity and work done so this should better represent efficiency of a task done instead of the perf/W metric that is better suited to continuous workloads such as found in 3D games.

The left axis thus represents the total system active energy usage for the benchmarks. Alongside I also depicted the average power over the length of the benchmark run. The less energy a platform consumed, the better it is in efficiency and thus battery life. The average power metric is a secondary metric that in this case plays less importance, however still should be considered in the case of thermal envelope limitations.

The results are colour-coded in shades of different SoC manufacturers and are also sorted by newest generation to the oldest by each SoC vendor, in the order as listed in the legend.

Starting off we run the SPECint2006 suite which focuses most on integer workloads.

The first results are interesting and the first thing we notice – particularly in contrast to the last time we looked at SPEC – is that we now finally have SoCs which make a significant leap in performance from the tight grouping we’ve seen over the past few years.

The Exynos 9810 fares extremely well in execution and IPC-bound benchmarks such as 400.perlbench, 403.gcc, 456.hmmer, and 464.h264ref, where we see a 66 to 88% increase in performance. In mixed workload benchmarks the M3 cores also fare well but don’t quite show the improvement we had expected and seen in less memory intensive benchmarks in SPEC and GeekBench 4.

462.libquantum deserves a special mention because it’s one of the few workloads that even with active cooling the SoC wasn’t able to maintain its peak performance as average power sustained at 4.8W.

I also have to remind reader that the devices were actively cooled in a reduced temperature environment, this is because the whole benchmark run takes 2-3 hours and we’re trying to look at peak performance. Transactional workloads are nowhere near this long-running and thus active cooling is warranted.

The Snapdragon 845 and Kryo 385 Gold/Cortex-A75 cores also fare relatively well compared to their predecessors. The new chip is able to show an average 30% improvement over the Snapdragon 835, even though the new SoC is handicapped. The limitation and regression of the memory subsystem is clearly visible in the results of the 429.mcf and 471.omnetpp workloads which are the most memory latency sensible benchmarks of the integer suite. Here the S845 respectively doesn’t manage to show an improvement and even actually shows a performance regression over its predecessor.

ARM had promised that the A75 would bring increased performance at the same efficiency. Usually this means same performance/W but for SPEC also means the same total energy usage at peak performance. ARM’s claim couldn’t be more validated than in the results here as we see the Snapdragon 845 within spitting distance of the Snapdragon 835’s energy usage throughout most of the workloads, sometimes winning and sometimes losing. Overall the Snapdragon 845 actually does 6% better than the Snapdragon 835. Because the energy usage is roughly the same, it means that the increase in performance came with a linear increase in power, again something which we can see throughout the results. As long as power remains under the sustainable thermal envelope of a device, having a higher power usage shouldn’t be of issue for transactional CPU workloads which are the most commonly found scenarios.

The Exynos 9810 marks a stark contrast to the Snapdragon 845 as its energy usage isn’t nearly as good. In fact at peak performance we’re seeing an overall regression over last year’s Exynos 8895. We expected the M3 cores to use a lot of power at peak frequency, but had hoped at least more competitive efficiency. The fact that we’re actually seeing a regression in efficiency over the M2 is worrying as it means that the increased performance comes at a price which will be visible in battery life.

I had hoped the M3 cores would come in at 2.5-2.8W usage as that would have left a bit of thermal headroom for at least dual-core operation at the peak frequency, however Samsung pushed the TDP and frequencies further above that for single-core usage.

Moving on to SPECfp2006 we should see very large theoretical increases from both new SoCs as their respective new microarchitectures have significant changes in the floating point execution pipelines. The Exynos 9810 indeed manages to largely fulfil the expectations with up to nearly 2x increases in several benchmarks.

4 out of the 7 floating point benchmarks run here are very memory latency sensitive and that’s where the Snapdragon 845 posts the smallest gains over the Snapdragon 835. 470.lbm is the outlier here as we see outstanding gains for the S845 – oddly enough outpacing the E9810. The Snapdragon 820 and its Kryo cores still dominate this benchmark so it looks like the benchmark has a peculiar set of characteristics, one among them is having extremely large inner loops which might put stress on instruction window limitations of the cores.

The energy characteristics for the Snapdragon 845 are similar as those seen in the integer benchmarks: it matches the Snapdragon 835 and even lands within 0.5% of the latter total energy usage for the whole suite. Again, the power usage is higher at an average of 2.32W for the S845 vs 1.69W for the S835, but still within reasonable levels.

The Exynos 9810 again does not fare well as it’s only able to show a meagre efficiency improvement, even though the performance boost is 71% over the Exynos M2. Average power usage is at 3.78W, again this might not be that problematic as the most heavy floating point workloads is JavaScript usage when loading webpages, a task that is by definition bursty and transactional.

One thing to note as interesting is the difference in scaling on the Exynos 9810 and Snapdragon 845 between both integer and floating point average power. Samsung’s power only increases 8% for floating point while Qualcomm/ARM’s solution sees a larger 30% jump. I don’t know if this points out to more efficient floating point execution engines on Samsung’s part or if ARM has the more efficient integer core.

Moving on to the aggregate view of the SPEC suites we should have quite a lot more confidence in judging both new SoCs. The Samsung Exynos 9810 improves performance by 71% in integer and 69% in floating point workloads and respectively regresses by 12 or maintains the same energy usage as the Exynos 8895. The Snapdragon 845’s performance boost is smaller coming in at 30% for integer and 37% for floating point, and the S845 also is able to post this improvement while keeping energy usage stable.

It’s when we try to compare the Exynos 9810 versus the Snapdragon 845 where we start to see issues when trying to reconcile the fact that the Galaxy S9 is powered by both SoCs. With its new microarchitecture and significant silicon budget, the Exynos 9810 only manages a 22% and 17% lead over the Snapdragon 845, a stark contrast to the much larger discrepancy that we had previously analysed in GeekBench 4 measured coming in at 37% and 68% for integer and floating point workloads. On top of that, the Exynos’ performance lead comes at a steep price of energy efficiency, as under SPEC the Samsung SoC had to use 62% and 35% more energy to complete the tests. Indeed this is something I had to practically experience, as the Exynos S9 required a partial battery recharge to be able to complete the SPEC suite, whereas the Snapdragon 845 managed within a battery charge.

GeekBench 4 Single Core

This still didn’t actually answer the question of which SoC is actually the more efficient micro-architecturally. We know the Exynos 9810 loses at full performance, but that’s also mostly because S.LSI pushes the clock very high at cost of voltage and efficiency. The best comparison would be if one clocked down the Exynos to the Snapdragon 845’s performance and re-measure the efficiency. In the interests of finishing this review have opted to not yet modify the device and root it to gain full DVFS control, so that will have to come later. But what I could do is use Samsung’s battery saving mode. The “CPU limiter” included as an option in Samsung’s battery savings modes caps the frequency of the M3 cores to 1478MHz and also changes other things such as scheduler settings.

Coincidentally, running under this mode quite closely matches the posted performance of last generation’s SoCs, both in SPEC as well as GeekBench, which gives us a good iso-performance comparison to that generation. Here the Exynos 9810 fares extremely well as it’s 28% more efficient than the Snapdragon 835 and 45-48% more efficient than the Exynos 8895.

However it doesn't make much sense to compare it to last generation, as the competition right now is what matters. What we can do is a little extrapolation. Assuming a linear increase in energy with a linear increase in performance, how would the Exynos 9810 fare against the Snapdragon 845 if use used the CPU limited data-points as a lower base-line? Unfortunately it doesn’t look good as even with linear scaling, the Exynos 9810 would use up more energy than the Snapdragon 845 at peak performance with a deficit of 8% and 4%. In reality this deficit would be larger as the increased performance doesn’t come with a linear energy increase but rather an exponential one. So at least at first view, the Exynos 9810 looks less efficient than the Snapdragon 845 across the board, and seemingly mathematically impossible to match.

In a vacuum, the Exynos 9810 could be seen as a good improvement over the Exynos 8895. However Samsung LSI isn’t only competing against itself and iterating on its products, it needs to compete against ARM’s ever-evolving offers as well. Unfortunately it feels like S.LSI keeps being one generation behind when it comes to efficiency – the A72 beating the M1, the A73 beating the M2 and now the A75 beating the M3. If you were to shift the microarchitectures one year ahead in Samsung’s favour then suddenly we would have had a much better competitive situation. What needs to happen with the M4 is a much larger efficiency boost to remain competitive with ARM’s upcoming designs and actually warrant the use of an internal CPU design team. Currently a 17-22% performance lead does not seem worth a 35-58% efficiency disadvantage along with the 2x higher silicon area cost.

The big question remaining is how the synthetic performance translates into real-world performance and battery life.

The Exynos 9810 - Introducing Meerkat System Performance
Comments Locked

190 Comments

View All Comments

  • id4andrei - Tuesday, March 27, 2018 - link

    All reviewers go gaga for geekbench scores with iphones/ipads as well. In this case the GB scores prove that at least in chip design Samsung has made a huge leap. As the review has outlined, the problem lies with the scheduler and DVFS which Samsung can and should address.

    If "Samdung" is so bad at hardware design, how do you call Apple's high priced iphones of the last 3 years that could not sustain chip performance and had to be throttled so as to not crap out. All initial reviews were glowing but they were all impervious to the impeding throttling.
  • name99 - Tuesday, March 27, 2018 - link

    Dude, you really do yourself no favors by struggling so hard to criticize Apple.
    Apple's throttling has NOTHING to do with the CPU per se (ie the CPU is not generating excessive heat beyond spec, or because it has been running too fast for too long), it has to do with the BATTERY and with a concern that, if CPU performance were to spike the battery could not supply enough current.

    Very different problem, nothing to do with the CPU design. A real problem yes but totally irrelevant to the issues being discussed here.
  • Matt Humrick - Wednesday, March 28, 2018 - link

    Apple's big CPU and GPU are susceptible to thermal throttling when running sustained workloads too.

    Also, having to throttle a processor within a year of sale because its transient current requirements overwhelm the power delivery system is most definitely a design flaw.
  • Icehawk - Friday, April 6, 2018 - link

    My wife’s 6S is still working at 100% after several years, I get the feeling the amount of people affected is overblown as pretty much anything anti-Apple is. I do think Apple needs to look at a better way of dealing with this but it’s also not the armeggedon somemake it out to be. I am far from a Apple fanboy but I do like their iOS products but I am sure someone will make a retort of that nature. I’d say the same thing about the Samsung chip - not great but it is performant, perhaps if we stop thinking each year a new phone should blow us away it would help us be more realistic.
  • Lavkesh - Tuesday, March 27, 2018 - link

    "In this case the GB scores prove that at least in chip design Samsung has made a huge leap" - Please explain huge leap here? The new chip barely outperforms the older SOC.
  • ZolaIII - Monday, March 26, 2018 - link

    I am very disappointed with both SoC's. Qualcomm wasted so much space on bad L4 cache which only added to latency & generally wasted more. The 30% is enormous even if new A75 cores are 35% bigger (would be 50% with ARM's L2 reference cache size) I don't know about A630 vs A540 size but if it grown-up let's say 10% the cores & GPU would together accommodate for around 15~20% leaving L3 & L4 responsible for the rest. Would be much better they used it for GPU as it could had been 2x the size then. I am also very disappointed with new cache hierarchy as it turns out to be stupid and a waist of silicone. Seams to me neither SoC used good scheduler nor scheduling by the looks of things it seems Samsung used the CAF HPM sched settings for Snapdragon SoC very aggressive patched interactive without any restraints whatsoever & no hotplug whatsoever which is very south from optimal, reference QC platform seams to had at least used hotplug (as their is no other way to explain the difference of almost 1W in GPU testing as two vs four A75's active). On the other hand seems Samsung used Power aware schaduler instead HPM & very granulated hotplug producing very bad results as those are directly confronted two things & when splashed together can only result in catastrophic result. I prefer HPM configured to be used with limited task packing and a high priority tasks enabled with significant increase of time interval for it (so that it can skip CPU sched limit), for CPU sched interactive traditional not patched with tree step load limitations (idle so that it doesn't jump erratic on any back shade task, ideal that is considered as best sustainable leakage for given lithography & max sustainable for two core's [only on big cores] i also use boost enabled & set to ideal frequency one [same as in interactive]). Preferred to use core_ctl hotplug disabled for the two little & two big cores so that they never get switched off from it. I won't go further in details about it hire as its pointless. I find this idea balanced between always available/needed/total performance as most of the times two of each course are enough for most of tasks & if not it's not a biggie to wait for other two to kick in. There is a minor drow back in responsiveness on lite task's but actually it works as fast as possible on hard one's flagged as heavy tasks like for instance Chrome rendering. It's also very beneficial to GPU workloads where even switching of two little core's and giving even 100~150mv headroom to GPU means much.

    Sorry for getting a bit deep regarding how complete scheduling mechanism should be done but I had an urge to explain how it should be done as it's so terrible done in the both cases examined hire.
  • tuxRoller - Wednesday, March 28, 2018 - link

    It's not at all clear that the hpm is meaningfully better (much faster or much more power efficient) than a proper schedtune + energy model implementation.
    Scheduling is just ridiculously hard. Adding the constraints of: soft-realtime requirements, minimal battery usage, AND an asmp and you've got the current situation where there's not yet a consensus design. We are, however, starting to see signs of convergence, imho.
  • zeeBomb - Monday, March 26, 2018 - link

    I came...and I finally saw
  • phoenix_rizzen - Monday, March 26, 2018 - link

    Ouch. The Exynos S9 is just barely better than the Exynos S7. :( And that's what Canada's going to get.

    Here's hoping they can improve things via software updates. Was considering the S9 to replace the wife's now dead S6. She's been using my S7 for the past two months while I limp along with a cracked-screen Note4. Other than the camera and screen, this isn't looking like much or an upgrade for being two generations newer.

    Maybe we'll give the ZTE, Huawei, and Xiaomi phones another look ...
  • mlauzon76 - Monday, March 26, 2018 - link

    Samsung Exynos 9810 (Europe & Rest of World)

    Canada is the 'rest of [the] world', but we don't get that version, we never get anything with the Exynos processor, we get the following one:

    Qualcomm Snapdragon 845 (US, China, Japan)

Log in

Don't have an account? Sign up now