System Performance

As we’ve extensively covered in various over the last year and more, CPU performance alone doesn’t signify all that much if the system isn’t able to properly take advantage of it in order to achieve better user experience.

Software here plays and incredibly important role, and we’ve seen some devices fall face flat in this regard. Last year’s Exynos 9810 powered Galaxy devices in particular made it abundantly clear just how much of a user experience difference this can make, vastly overshadowing the actual hardware performance.

For the Galaxy S10, we expand on our initial MWC coverage regarding system performance between the two chipset variants. Here we saw clear indications that the Snapdragon 855 variant would again win in these set of benchmarks, and likely end up as the better device in terms of user experienced performance.

We’ve retested the numbers with our own in-house devices, so let’s take a look if and how things have changed:

PCMark Work 2.0 - Web Browsing 2.0

Starting off with the PCMark web-browsing workloads, the Snapdragon 855 variant of the Galaxy S10 leads the benchmark scores. Even though we’re seeing the Qualcomm chipset in a production device now, it still looks to lose out to the Kirin 980 devices. Both Samsung and Huawei now have “performance” modes in the device settings. For Huawei, as per company product management explanations, this is actually the intended full performance of the device while the default mode is slightly more battery friendly for the mass-market users who aren’t as performance sensitive.

It’s not yet exactly clear what Samsung’s performance mode changes compared to the “optimised” default setting, however I’ve also seen that this latter setting can result in throttled performance which actually results in Snapdragon performance numbers falling back to the range of the Exynos 9820 figures.

Samsung’s new “CPU Limiter” for the Galaxy S10 now works fundamentally differently than last year; it doesn’t actually limit the peak frequency the CPU can reach,  but rather limits the total CPU capacity to 70% in the scheduler, meaning multi-threaded workloads will be throttled. Frankly I find this silly as the device doesn’t inherently become more efficient as it still has access to the higher frequencies, and thus the battery advantage of this function isn’t nearly as great as what users will have experienced with the Galaxy S9.

Correction edit: The CPU Limiter does seem to work similarly and limiting CPU frequencies, however for some reason its activation and effect is seemingly delyed and isn't immediate following a change in settings.

PCMark Work 2.0 - Video Editing

The video editing workload is still something dominated by Qualcomm. The performance here seems to be dictated by the responsiveness of the little cores. In absolute terms, the differences aren’t big and this part of PCMark isn’t very indicative of overall system performance.

PCMark Work 2.0 - Writing 2.0

The one test that is actually most indicative of experienced device responsiveness is the Writing 2.0 workloads. Here the Snapdragon 855 falls in at the top of the performance charts along the Kirin 980. The Exynos 9820 Galaxy S10 also does relatively well here, but just falls short of the competition.

What is however most important is that this is now the first Exynos chipset in several years where S.LSI was able to deliver a scheduler and DVFS system that wasn’t absolutely abysmal, as evidenced by the massive performance difference between the Galaxy S10 and past Exynos devices at the very bottom of the chart.

PCMark Work 2.0 - Photo Editing 2.0

The Photo Editing workload again showcases similar improvements on the part of the Exynos. Here Qualcomm still has a very large performance advantage which simply might be due to better GPU acceleration for the RenderScript workloads which are part of the photo filter editing in this test.

PCMark Work 2.0 - Data Manipulation

Finally the Data manipulation workload sees the Snapdragon Galaxy S10 again at the top of the charts, with the Exynos 9820 slightly trailing it.

PCMark Work 2.0 - Performance

Overall, the Snapdragon 855 Galaxy S10 ends up as our top performing phone in PCMark. The Exynos 9820 unit trails behind, however does showcase significant improvements over previous generation Exynos phones.

Web JS Benchmarks

Switching over to web-browser based benchmarks, we’re testing inside a simple OS WebView shell as this is most representative of user-experience when browsing websites through third-party apps.

Speedometer 2.0 - OS WebView

In Speedometer 2.0, both Galaxy S10 devices are neck-in-neck within margins of error. The performance improvements of the Snapdragon 855 over last year’s Snapdragon 845 in this test seems relatively conservative, the Kirin 980 clearly is able to showcase a bigger performance lead.

The Exynos 9820 showcases dramatic performance gains over last year’s Exynos 9810. The removal of the abysmal hot-plugging mechanism means that the big CPU cores are able to actually run at full speed all while having secondary threads on the other big and middle cores.

WebXPRT 3 - OS WebView

In WebXPRT 3, the Snapdragon 855 manages to match the Kirin 980 while Exynos 9820 trails slightly behind.

JetStream 2 - OS WebView

Finally, I wanted to add in results of the brand-new JetStream 2 test that was released just two days ago and we’ll likely looking to adopt in the future (after more careful analysis). An interesting aspect of this test is that it’s using web workers to parallel workloads, something we usually never had in the past for browser-based JavaScript benchmarks.

Here the Exynos 9820 has a bigger disadvantage than the Snapdragon 855. The fact that the Kirin 980 scores identical to the Snapdragon means the performance shouldn’t be linked to the lower performance middle cores, but still strongly dependent on the big core performance. Unfortunately this seems to be another benchmark that doesn’t agree with Samsung’s CPU microarchitecture, with the Exynos S10 falling behind by 22%, even scoring less than the Snapdragon 845 of last year. This workload also doesn’t seem like a constant sustained test so it’s likely that scheduler responsiveness will play a role.

Scheduler & DVFS responsiveness

To investigate scheduler responsiveness and device DVFS settings, we fall back to our scaling performance ramp test. This is a fixed instruction chain workload with fine-grained timing collection every certain amount of instructions. By converting the time taken for every instruction block we can convert this into the frequency of the resident CPU that the workload is currently scheduled on, giving us detailed frequency information over time.

We’re looking at both Galaxy S10 units as well as the Mate 20 with the Kirin 980. For the new Qualcomm chipset what stands out is that the Galaxy S10 is indeed more aggressive in its scaling than what we’ve seen in January on the Qualcomm reference platform, reaching peak performance in 67ms rather than 95ms. It’s interesting that now even though the Qualcomm chipset has a clear scheduler and DVFS speed advantage over the Kirin 980, it still only is able to match or slightly lose out to the HiSilicon chip.

The results of the Exynos 9820 aren’t nearly as performant as on the Snapdragon Galaxy S10. Here we’re seeing that the chip first scales and resides on the small A55 cores for up to 83ms before it switches over to the Cortex A75 cores. What is extremely weird here is that the workload is staying on the middle cores for a mere 15ms before it switches over to the big M4 cores, finally reaching peak performance at around the 143ms mark, essentially twice as slow as the Snapdragon chipset.

We’ve seen a similar story last year with the Exynos 9810, and the issue is inherently tied to the scheduler. Make no mistake here, the Exynos 9820 behaves infinitely better than the Exynos 9810, however I expected more of the new chip. One of the things I did last year was to introduce two new big changes to the scheduler’s load tracking mechanism; halving the PELT half-life from 32ms down to 16ms which by itself doubled the responsiveness. On top of that I’ve added util_est to increase performance of short periodic workloads that otherwise would have lost their load utilisation faster.

For the Exynos 9820, what Samsung did was essentially also adopt these two important changes… and that’s about it. Although the new chipset comes with a new scheduler that does make efforts to schedule things around in an energy efficient way, the core issue of the scheduler load being slow hasn’t been further improved beyond what I myself was able to achieve last year. Currently the Exynos 9820 is the only flagship Android SoC that still uses PELT in its scheduler as a load tracking mechanism as both Qualcomm and HiSilicon are making use of WALT, which is massively more responsive. Google actually wants to drop WALT out of the Android Common Kernel, however this happened only after PELT was made to be as responsive as WALT. One very important patch to achieve this is unfortunately missing from the Exynos 9820’s BSP which means as a delivered product the Exynos Galaxy S10 just has lower responsiveness. In next year’s Exynos we’ll probably finally see things equal out, however this will by then be 4 generations and years of Qualcomm SoCs being superior and giving better user experience simply because they have the better software stack.

That being said, it’s not all doom and gloom for the new Exynos 9820 Galaxy S10. What the scheduler lacks is actually made up by touch boosting as well as Android framework integrated boosters which are triggered by activity switches. These mechanisms actually help out a lot the user experience of the Exynos Galaxy S10 beyond what we can actually measure in standalone benchmarks such as PCMark or the web tests. In my subjective experience with both phones, yes the Snapdragon unit was slightly faster, but if I didn’t have both devices side by side to compare, it would be have been something quite hard to notice. What is important is that the experience on the Exynos 9820 is leagues ahead of what we’ve seen in the Exynos 9810 devices and past chipsets. Some of these OS-side boosters seem to have made it into the Android P update of Exynos 9810 devices, so while the kernel as remained largely unchanged, at least this part benefits last year’s devices.

Overall, both the Snapdragon 855 and Exynos 9820 Galaxy S10 give among the very best performance experiences among current Android phones, even if the latter has some rough edges here and there.

Inference Performance: APIs, Where Art Thou? GPU Performance & Power
Comments Locked

229 Comments

View All Comments

  • xian333c - Wednesday, April 17, 2019 - link

    How to buy that unicorn on table in ur shout?
  • Brightontech - Sunday, April 21, 2019 - link

    it is an awesome phone
    <a href="https://www.brightontech.net/2019/04/audiovideo-ed... Editor and Video Converter</a>
    Video Editor and Video Converter
  • Jhereck - Tuesday, April 23, 2019 - link

    Hi Andrei another question regarding the patch designed to increase PELT resonsiveness : is there any way a third party kernel can include it, therefore making s9 and s10 the devices they should be ?

    You know like last year when you tried to play with s9 exynos kernel in order to match snapdragon power and power efficency ?

    Thanks in advance
  • Rixos - Thursday, May 2, 2019 - link

    It's kind of sad, I was actualy looking at the s10e as a replacement device for my galaxy S7 but as I live in Europe I would be getting the Exynos variant. Worse audio quality, less processing power and worse camera results. Basically seeing this kind of ruined the purchase for me. In some sense I wish I would not have seen it, the S10e is likely still a great upgrade for my S7 but knowing that there is a better version out there just ruins it for me. I guess ignorance sometimes really is bliss.
  • theblitz707 - Thursday, May 23, 2019 - link

    I see this is in every review. I actually went to stores and used my phones ambient light sensor and an another phones flashlight to measure display brightnesses. Although slightly inaccurate lg g7 gave a 1050lux reading with boost on.(all test on apl100) Taking that as a base s9 plus did 1020 s10 plus did 1123 and p20 pro did around 900 when i shone my flashlight to each sensor. So why everyone makes it seem like they are less bright than they actually are? Does using a flashlight to trigger high brightness impossible to imagine? Let me tell you those oled screens get very bright with high ambient light like outside on a sunny day.
  • ballsystemlord - Monday, June 3, 2019 - link

    Spelling and grammar corrections. I did not read the whole thing, so there maybe more.

    Samsung new L3 cache consists of two different structures
    Possesive:
    Samsung's new L3 cache consists of two different structures

    Similarly, the A75's should be a ton more efficient the A55 cores at the upper performance points of the A55's.
    Missing "than":
    Similarly, the A75's should be a ton more efficient than the A55 cores at the upper performance points of the A55's.

    Arm states that the new Cortex A76 has new state-of-the-art prefetchers and looking at what the CPU is able to do one my patterns I'd very much agree with this claim.
    Missing "to":
    Arm states that the new Cortex A76 has new state-of-the-art prefetchers and looking at what the CPU is able to do to one my patterns I'd very much agree with this claim.

    The nature of region-based prefetchers means that fundamentally any patterns which has some sort of higher-level repeatability will get caught and predicted, which unfortunately means designing a structured test other than a full random pattern is a bit complicated to achieve.
    "have" not "has" and a missing y:
    The nature of region-based prefetchers means that fundamentally any patterns which have some sort of higher-level repeatability will get caught and predicted, which unfortunately means designing a structured test other than a fully random pattern is a bit complicated to achieve.

    Switching over from linear graphs to logarithmic graphs this makes transitions in the cache hierarchies easier to analyse.
    Excess "this" and analyze is with a "z":
    Switching over from linear graphs to logarithmic graphs makes transitions in the cache hierarchies easier to analyze.

    Indeed one of the bigger microarchitectural changes of the core was the addition of a second data store unit.
    Missing comma:
    Indeed, one of the bigger microarchitectural changes of the core was the addition of a second data store unit.

    ...we see that in the L3 memory region store curve is actually offset by 1MB compared to the flip/load curves, which ending only after 3MB.
    "ed" not "ing":
    ...we see that in the L3 memory region store curve is actually offset by 1MB compared to the flip/load curves, which ended only after 3MB.

    "Traditionally such misses are tracked by miss status holding registers (MSHRs), however I haven't seen Arm CPUs actually use this nomenclature."
    This is almost certainly a run on sentence with missing punctuation. Try:
    "Traditionally, such misses are tracked by miss status holding registers (MSHRs). However, I haven't seen Arm CPUs actually use this nomenclature."

    "Again to have a wider range of performance comparison across ARMv8 cores in mobile here's a grand overview of the most relevant SoCs we've tested:"
    Missing comma:
    "Again, to have a wider range of performance comparison across ARMv8 cores in mobile here's a grand overview of the most relevant SoCs we've tested:"
  • giallo - Monday, June 17, 2019 - link

    how much did they pay you to write this bullshit? you must be true downs
  • theblitz707 - Monday, August 19, 2019 - link

    i discovered something about display brightness on oleds recently. I did a test with a7 with auto brightness on.

    Lets assume, on a slightly dark room you set your brightness to 25nits(whites), so when you go out to the sun phone boosts around 750-800 nits.

    Now lets assume on a slightly dark room you set your brightness to 250 nits, now when you go out to the sun phone boosts to 900nits. (what i actually did was not go in a dark room but while i was outside i covered the sensor with my hand so it thought i was in a dim place)

    I used to assume everytime you go out to sun it would get maxed but apparently it still depends on what you set your phone before.(dumb a bit if you ask me, cuz you know, its THE sun, brightest thing..) I believe this might be the reason why you didnt reach to 100APL 1200nits.

    P.s. I know every brightness sensor is different but i had tested lg on full white and i had gotten 1050 lux, i also tested s10 or plus, all white and i had gotten 1120lux on white,100APL.(It was painfully hard to find the sensor to shine the flashlight, its somewhere around upper part of the phone under the display).

    It would be cool if you retested the brightness in this way:

    1- After you put auto brightness on, Go in a very dark room or cover the sensor, so phone put itself to a dark brightness, after that happens, set the brigthness to max while you are still in the dark room.(auto is still on).
    2- Now go under sun or shine a phone flashlight to sensor and test the brightness on white APL100. That would be really nice.
  • theblitz707 - Monday, August 19, 2019 - link

    lg is g7 on boosted, forgot to mention

Log in

Don't have an account? Sign up now