Performance & Battery Results

System performance was the key concern for the Exynos 9810 Galaxy S9. Having addressed the biggest issues in terms of scheduler and DVFS scaling, it’s time to check how this impacts our benchmark results. Again I like to comment that the following figures are not the best scores that the device achieved; but they are with the configuration that in my opinion best balanced performance and battery life given the time invested.

To recap what we’re looking at: the original firmware S9 (E9810) scores showcase the unmodified behaviour; the custom 1 modifications simply limit performance to 1794MHz on the M3 cores and disable the higher clock boost modes. Custom 2 contains the more major kernel modifications which we've covered on the first page while maintaining the 1794MHz maximum clocks.

Custom 3 configuration maintains all mechanisms but raises the clock back to 2314MHz – a clock which based on some investigation in the kernel source code may have been the original maximum designed frequency the SoC, and incidentally the last frequency before major diminishing performance/power returns in terms of voltage scaling.

PCMark Work 2.0 - Web Browsing 2.0

In PCMark’s web browsing test 2.0 we see a major improvement from all of the custom configurations. The first variant’s performance boost was caused by the capacity scale shift towards the big cores and thus having more workloads migrated onto the M3’s. Custom 2 & 3 retained similar performance however the performance boost here over the stock configuration comes from the increased scheduler and DVFS responsivity. Raising clockspeeds further to 2.3GHz didn’t bring much improvement – improving performance here sees diminishing returns and making the cores more aggressive brings a larger power and battery degradation.

PCMark Work 2.0 - Video Editing

PCMark Work 2.0 - Writing 2.0

As noted in part 1, I said I was confident being able to quickly recuperate some of the performance degradations of the first custom kernel. The PELT changes alongside the tuning did bring us back above the stock kernel in the video and writing tests. It’s interesting to see here the difference that the increased 2.3GHz clock brings – everything else being equal, the writing test gets a big boost in the score. I suspect this is because of the PDF rendering part of the test which is more compute intensive and just outright CPU throughput-bound.

PCMark Work 2.0 - Data Manipulation

The Data Manipulation test didn’t see major differences between custom 1 & 2 – this test didn’t seem to be significantly influenced by the scheduler changes, and the score only scaled slowly with further aggressive and power-hungry modifications. Raising the clock back to 2.3GHz in turn gave us a good linear increase, pointing out to more long-running tasks and CPU capacity limits.

PCMark Work 2.0 - Photo Editing 2.0

The Photo editing benchmark was the test most affected by the scheduler and DVFS changes. Here we finally find the explanation for the Exynos SoC’s bad performance in this test: the frequency just doesn’t scale fast enough with the heavy-but-short-lived tasks. This test scaled up to scores of 13000 at the most aggressive settings with WALT, but again at far too great power costs for it to be reasonable.

Source: WALT vs PELT : Redux – SFO17-307

Again, Qualcomm seems to be well aware of this, as they use PCMark as a demonstration of their custom scheduler modifications. I’m aware of concerns that this may be not representative of real-world uses and there might be too much a focus on PCMark, but in my experience this is not the case and I still think it’s overall the best representation we have on device “snappiness”.

Indeed, both configurations with the scheduler modifications made the S9 significantly more responsive and among one of, if not the most responsive devices. There’s a big “but” consideration for real world usage though – I haven’t tuned the touch boosters of the phone. These were naturally tuned for the slower stock behaviour of the SoC. In general the WALT and PELT modifications have the end-goal of completely avoiding the need of such input boosting mechanisms and to save on power. Therefor my subjective experience of the phone being so fast might be just a temporary thing and for battery optimization we might tone it down a bit through the removal of the input boosters. Unfortunately short of having a robotic arm and special benchmarks, this is all nearly impossible to objectively test.

Edit: I ended up trying a kernel with completely turned off input boosters and the phone still perfoms very well.

Another point I want to clarify when I talk about device responsiveness, is that I generally use phones without animations enabled as it just provides for a much faster UI experience. Under this use-case it’s very noticeable to see performance differences between devices, as the default animation durations can hide a lot of hiccups.

Speedometer 2.0 - OS WebView

In terms of web benchmarks we start with SpeedoMeter 2.0. This first test saw a smaller 7% boost from the new scheduler settings, so generally the performance here wasn’t an issue of performance responsiveness but rather of raw CPU capacity. Raising the clock back to 2.3GHz brings the performance back up near the Snapdragon 845 levels.

WebXPRT 3 - OS WebView

WebXPRT was also extremely sensitive to the scheduler settings, as we see a 10% increase on the custom 2 configuration. This was also one of the use-cases where the new PELT behaviour actually outperformed WALT as I was only able to reach a score of 76 with the former. Again the score here with the custom 2 configuration seems to be the highest reasonably-reachable performance under 1794MHz, and anything above that seems to be CPU capacity limited. The 2.3GHz configuration brought the performance back to Snapdragon 845 levels.

I also want to add that the performance levels in the web benchmarks here are at the highest achievable for the Exynos, and I don’t think any more scheduler or software optimisations will bring much. Especially as locking the cores to their maximum frequency doesn’t improve performance by much more.

Battery Life

The balance between performance and battery life is again a key aspect and issue of the phone and the SoC. I’ve tried myriads of configurations but simply wasn’t able to exceed the battery results of the first custom configuration. Unfortunately the physics here just overrule any possible software optimisation, and any performance increase will mean that we’re doing computations at higher performance states of the SoC, and thus we’ll be burning more energy per unit of work.

Web Browsing Battery Life 2016 (WiFi)

The custom 2 configuration brought a performance improvement, however this came at a cost of some battery life. This was a reasonable compromise and in my opinion the best-case scenario for the Exynos 9810 S9. Boosting the cores to 2.3GHz brought the 9810 to parity with the Snapdragon 845 in nearly all benchmarks, but this regressed battery life even further.

The juxtaposition between the stock results of the S9 versus the custom 3 configuration is interesting: We’re achieving similar battery life in both scenarios, just short of 7 hours. However the custom 3 configuration brings a 25-40% performance boost across a variety of tests. I might be beating a dead horse here, but again it shows that the Exynos 9810 could achieve just much better results depending on which direction one opted to optimise for, either performance or battery life.

PCMark Work 2.0 - Battery Life

I didn’t cover PCMark battery life in the first part but I wanted to make sure I cover all my bases for this piece. Here both custom 2 and 3 saw battery life regress versus the stock behaviour, but again in both cases that’s simply due to the higher overall performance. The delta from the increased 2.3GHz clock rate is a lot smaller here than in the web test, and that’s due to PCMark though being a lot more interactive in terms of continuous workloads. It has fewer really heavy tasks such as loading webpages, which use the higher frequency states of the M3s for relatively longer times.

Scheduler mechanisms: WALT & PELT Conclusion & End Remarks
Comments Locked


View All Comments

  • N Zaljov - Sunday, April 22, 2018 - link

    For this part, Spock should‘ve used a tunnel bore instead of a mere chainsaw, because a chainsaw doesn‘t seem to accomodate the right amount of „POWER!“ that one would require in order to deal with Samsung‘s crapload of shady implementation. SCNR
  • djayjp - Friday, April 20, 2018 - link

    Wow, amazing work. The definition of above and beyond. I would submit this data to Samsung.
  • StormyParis - Friday, April 20, 2018 - link

    Fascinating. Thank you !
  • mad_one - Friday, April 20, 2018 - link

    Lovely article!

    Software can still play a part in the web workloads, as the Javascript and browser engines are probably better tuned for the ARM cores. Of course tt could also be the M3 core struggling to extract enough ILP out of the branchy and cache unfriendly JS code, ARM has certainly tuned their cores for this over the years.
  • repoman27 - Friday, April 20, 2018 - link

    Outstanding work, and much appreciated. Thank you, Andrei!

    I fully recognize that one only has so much time to commit to writing pieces like this, and that it requires a fair amount of personal interest in the subject matter at hand to do it right. However, it would be great to see Anandtech do a deep dive into the iPhone battery issue. Obviously Apple is intentionally opaque regarding a fair amount of the iPhone and iOS internals, which would make it somewhat more challenging. But I have yet to see anyone publish anything that even quantifies the basics of the reduced performance modes introduced by the various software updates. I can't imagine it would be too hard to figure out what the maximum clocks are with a new battery vs. what appear to be four distinct lower performance modes, or to determine what metrics are used to trigger those modes. Maybe the folks at the kiosk that does aftermarket battery replacements at the local mall would be willing to set aside a box of pulled batteries for testing? Such an article would arrive late as far as the media cycle is concerned, but this is an issue that continues to affect hundreds of millions of people worldwide.

    A few years back, Brian Klug used to catch a lot of flack for being biased, before he (and Anand) left to join Apple. And maybe you'll end up at Samsung in the future, like Kristian. But while I think your tone was quite even handed and appropriate in this article, you seemed much more inclined to denounce Apple as deserving of a class-action lawsuit before doing any in-depth testing in regards to their recent power / performance issues. In your opinion, what is the appropriate response from Samsung in this situation? I mean, obviously pushing out a software update that improves performance would be a good start, but should owners of Exynos 9810 variants of the Galaxy S9 sue for damages and extract their pound of flesh?
  • BurntMyBacon - Monday, April 23, 2018 - link

    @repoman27: "But while I think your tone was quite even handed and appropriate in this article, you seemed much more inclined to denounce Apple as deserving of a class-action lawsuit before doing any in-depth testing in regards to their recent power / performance issues."

    I think the difference in tone reflects the difference in situation. In Samsung's situation, the product came to market with a set level of performance and battery life. Very early in the lifecycle of the product, It was discovered that better software would improve their situation to a more or less extent on one or both fronts. In Apple's situation, the product came to market with a set level of performance and battery life. After a certain time period and as a direct result of a software update, performance suddenly and inexplicably (until it was investigated) dropped for older phones (more cycles on the battery).

    Samsung's situation left their solution looking immature at best and their engineers looking incompetent at worst. In either case, their misstep appears to be unintentional and only serves to hurt sales of a new product. Apple's situation left them looking misguided at best and abusive(?) at worst. In either case, their actions appear to be intentional (well meaning or not). The actions only affect phones later in their life cycle and, whether as an unintentional side effect of their actions or as the primary goal of their actions, Apple stands to gain by virtue of prompting upgrades. Some people tend to believe the upgrades were the primary goal due to Apple's locked in ecosystem design and marketing strategy, but it could just as easily have been an (un)fortunate side effect of them trying to mitigate another potentially serious blemish to their user experience. Perhaps a case of the cure being worse than the disease. Like you, I wouldn't mind a more in depth look at the situation that could help clarify this.

    In any case, I think the difference in tone comes down to the clear lack of intention on Samsung's part (they don't benefit from this) and potentially well meaning but certainly intentional actions on Apple's part.
  • B3an - Friday, April 20, 2018 - link

    Excellent article Andrei. One of the best on here in a long time.

    Glad i got a import Snapdragon S9+, because it seems no software update will ever properly fix the poor battery life and *actual daily usage* performance of the Exynos version. Absolutely pathetic how poorly Samsung handled all this though. So many poor decisions. Honestly the people responsible need to be fired. People shouldn't have to go out of their way to buy imports.
  • serendip - Friday, April 20, 2018 - link

    This article will probably be used as a chainsaw by Samsung top management to get rid of everyone who screwed up the Exynos S9. It's sad how seemingly chasing synthetic benchmarks led to bad decisions from chip design onwards.
  • madurko - Saturday, April 21, 2018 - link

    AFAIK they are comparing the smaller S9 Exynos (which has 3000mAh battery) vs. S9+ S845 US version (3500mAh). So the battery life obviously will be better with the bigger bro. But, anyway, this doesn't make the exynos version any better.
  • mczak - Friday, April 20, 2018 - link

    Very interesting article indeed.
    I agree the M3 core looks a bit oversized for a smartphone - but a tweaked version of it on 7nm might fare a lot better. For this generation, it definitely wasn't worth the effort over standard A75.
    And, by the looks of it, recognizing the power issues, samsung made things worse with an inadequate scheduler.
    I wonder if actually the SD845 could get better battery life at very little performance cost by disabling the highest frequency state - that sure looks inefficient as hell. (Albeit that could only widen the battery life gap between the two S9 versions...).
    The discrepancy between web tests and microbenchmarks (and spec) in efficiency is also quite interesting - while I'd agree it might be more difficult to extract good IPC of these web tests (putting wide cores at a disadvantage) apple seems to have successfully done so, though I'm ignoring if through software or hardware means.

Log in

Don't have an account? Sign up now