Galaxy S9 Exynos 9810 Hands-On - Awkward First Resultsby Andrei Frumusanu on February 25, 2018 6:45 PM EST
- Posted in
- Exynos 9810
- Galaxy S9
- Galaxy S9+
Following our launch article I promised an update on the performance scores of the Exynos 9810 variant of the Galaxy S9. I was able to have some time with one of the demo devices at the launch event and thoroughly benchmark it with a few of our common tests.
|Samsung Exynos SoCs Specifications|
|SoC||Exynos 9810||Exynos 8895|
|CPU||4x Exynos M3
One Core : 2.704 GHz
Two Core: 2.314 GHz
Four Core: 1.794 GHz
4x 512KB L2
4096KB L3 DSU
|4x Exynos M2
@ 2.314 GHz
|4x Cortex A55 @ 1.95 GHz
512KB L3 DSU
|4 x Cortex A53 @ 1.690 GHz
@ 572 MHz
@ 546 MHz
As a refresher, early in the year Samsung LSI had dropped a bombshell in claiming an astounding 2x single-thread performance improvement with the new Exynos 9810. While this initially caused a lot of controversy and discussions on the validity of the claim, early this year we exclusively covered the high-level micro-architectural features of the new Exynos M3 core and by then it was clear that the performance claims were not just marketing claims. The new Samsung CPU core is the first “very wide” CPU microarchitecture to power Android SoCs and the first to finally follow Apple’s footsteps in the direction of maximising single-thread performance. As a result it stands to be a very interesting - and ideally very powerful - SoC for the Android market.
Determining Clock Speeds
Firstly one of the biggest questions for me was confirming the final clock that Samsung would use on the Galaxy S9. We detected the clock as 2704 MHz, which is 200MHz less than the 2.9 GHz that Samsung's LSI division advertises for the chipset. What makes the story more compelling is that the 2.7 GHz clock is only achievable when one of the cores in the cluster is active - thus making Samsung employ scalable maximum frequencies depending on active core numbers in the big cluster. At two active cores the frequency drops down to 2314 MHz while three and four active cores the cores clock down to only 1794 MHz.
We can also confirm that the Mali G72MP18 GPU is running at a very conservative 572MHz. This is not what we had expected - the previous generation Exynos 8895 had a larger MP20 configuration, running at a similar 546MHz. The resulting performance gains for the GPU thus seem to be even lower than we had expected, as I was betting on a ~650-700 MHz clock for the graphics.
I was also able to confirm the cache configurations of the CPUs with help of our latency test. The L1D cache of the M3 cores is 64KB, up from the 32KB on the previous generation. The M3 cores also come with 512KB of private L2 caches, and a shared 4MB L3 cache.
The little A55 cores came at a surprise as they look to be in a separate cluster, rather than in a single DynamIQ cluster with the big cores. This creates something similar to a big.Little design, but each part of the 4+4 is its own DynamIQ cluster. So here it looks like Samsung has decided not to employ the optional L2 caches for the Cortex A55s, and instead the cluster solely relies on a shared 512KB L3 cache of the DSU. The latency scores to DRAM are outlandishly good and the best we’ve ever seen among current Android SoCs, so Samsung has definitely introduced a new generation of interconnect or memory controllers.
Parsing the Benchmark Results: Geekbench Looks Good
In our testing we were able to confirm the GeekBench 4 scores already leaked, where we saw the Exynos 9810 achieving excellent performance gains and vastly outpacing the Snapdragon 845, and coming into the territory of the Apple A10 and A11. Meanwhile versus the last-generation Exynos 8895, the floating point performance increases handily exceed Samsung’s projected gains of 2x as we see a 114% improvement even at the lowered 2.7GHz frequency.
When looking at the performance per clock it is clear how the Exynos M3 distinguishes itself as a much wider microarchitecture compared to any other existing CPU which powers Android SoCs.
Parsing the Benchmark Results: PCMark and Web Tests
Finally I stumbled upon some very questionable performance figures when testing system performance. I’m not going to go into the details for every benchmark as they are generally all painting the same picture:
What seems clear is that there is something is very very wrong with the Exynos 9810 S9+ that I tested. It was barely able to distinguish itself from last year’s Exynos 8895, let alone the Snapdragon 845 in the Qualcomm Reference Device which we previewed earlier this month. I looked through the system and monitored frequencies and indeed the big cores were reaching the maximum 2.7GHz core frequency. The only explanation I have right now is that it’s possible that the DVFS configuration, as well as the scheduler, are currently so conservatively tuned that there is barely any activity on the big cores.
I dug a bit more through the system and found out Samsung uses some new scheduler called “eHMP”. I’m not sure if this is something based on EAS but the system did use schedutil as a frequency governor.
One of the Samsung spokesmen confirmed to me that the demo unit were running special firmware for MWC and that they might not be optimized. I’m having a bit of a hard time believing they would so drastically limit the performance of the device for the show demo units and less so that they would mess around with the scheduler settings. I did get confirmation that Samsung is planning to “tune down” the Exynos variant to match the Snapdragon performance – however the current scores which I got on these devices make absolutely no sense so I do hope this is just a mistake that will be resolved in shipping firmwares and we see the full potential of the SoC.
Parsing the Benchmark Results: Graphics
On the GPU side, the lower cluster count of the new Mali G72MP18 is a surprise, as the minor clock bump is negated by the fact that the new SoC has two less GPU cores compared to the 8895. If the performance per clock per core between the G71 and G72 were the same then this would actually mean a downgrade in raw GPU power from the Exynos 8895, so any increase, if any, should come solely thanks to the architectural changes of the new G72 GPU, power efficiency improvements, as well as possibly SoC memory subsystem improvements.
In Manhattan 3.1 the Exynos 9810 sees a mere 7% increase and lags far behind the new Snapdragon 845’s Adreno 630.
In T-Rex, the increase is 18% which might be one of the benchmarks that Samsung sourced their 20% improvement from. Here the Exynos is more near to the performance of the Snapdragon 845.
I wasn’t able to properly measure power on the event demo devices, as they had different interface settings than my tool had been programmed with, so I only was able to make some inaccurate estimates based on coarse current readout from the system.
For CPU workloads, our usual CPU power virus used up 3.1W at 1-core 2.7 GHz loads. 2-core 2.3 GHz seemed to have floated around 3.1-3.5W, and a 4-core load at 1.8 GHz maintained this power consumption.
Over the following days I will need more time, and hopefully get some SPEC figures to paint a more accurate picture. For now the results could swing either way and be either positive or negative for the M3 cores. It’s clear that the higher frequencies have a very large power penalty, and Samsung should want to operate more in the low-to-mid frequencies, hence the current frequency scheme.
On the GPU side for Manhattan fluctuated between 4.5 and 5.2W, which is an improvement over the Exynos 8895. But again, this is still at a disadvantage compared to the Snapdragon 845.
Overall today’s quick benchmarking session opened up more questions than it managed to answer. Hopefully with more time we will be able to investigate the working of the new SoC and, fingers crossed, today’s results are not representative of shipping product as that would otherwise be an utterly massive disappointment.
Post Your CommentPlease log in or sign up to comment.
View All Comments
lilmoe - Wednesday, February 28, 2018 - link@tux
Hah! That's rich coming from someone providing zero evidence to their claims. Others have also argued that screen resolution doesn't impact perceived performance and battery life.
Google has a history of sloppy optimizations for Android, from touch and audio latency, to UI rendering, which Google actually discussed in multiple videos. They've long argued how "inefficient" it was to add hardware acceleration until they were forced by the community to support hardware acceleration in ICS. With all their "efforts", it wasn't until CPU power improved that it was actually possible to brute force a more "fluid" UI in Android, and that's with aggressive scheduling, and reduced useful features compared to other Android skins.
You know, we're bit different. I don't give companies the benefit of the doubt so easily.
ladyanita22 - Wednesday, February 28, 2018 - link@lilmoe you certainly have no idea what you're talking about. Actually iPhone chips are really, really powerful, and they've been ahead in single thread for many years. That's what matters the most for UI performance and JS, and it IS the reason why iPhones perform so much better at it than Android phones. Nitro helps, that's true, but strong SC performance is key here. Drawing more power doesn't have any effect on these simple UI tasks.
You're the one providing ZERO sources, and looking at your history it's pretty clear you hate Google or something. Android is indeed fast and snappy if implemented properly, even on slower SoCs.
lilmoe - Wednesday, February 28, 2018 - linkSure, OK.
Netwern - Friday, June 29, 2018 - linkIgnorant is a bliss.
Netwern - Friday, June 29, 2018 - linkNo, you're the one who is blabbering nonsense. I as a past loyal Android fan looking at what he explained and his past comment history, i can conclude that lilmoe knows well what's he's talking about. He even gets into all those technicalities maybe that's why you've missed the bus.
tuxRoller - Thursday, March 1, 2018 - linkI've provided a link to the Android docs that explains how, and where, to use hardware accelerated rendering. That shows both the current capabilities of the canvas api. I've looked for, but been unable to find analogous iOS docs.
You've not actually provided ANY EVIDENCE AT ALL.
ladyanita22 - Tuesday, February 27, 2018 - linkBy the way, it's been long since Android apps are turned into native code.
SydneyBlue120d - Tuesday, February 27, 2018 - linkDo You have any official source proving Samsung Touchwiz is using Vulkan instead of OpenGL? I haven't heard anything after this 2016 news:
Thank You very much.
lilmoe - Tuesday, February 27, 2018 - link@sydney
I really can't find it. I'm not sure to what degree it was utilized, but I'm sure I read last year that it's in actual use in the launcher and Samsung's browser after the nougat update.
ladyanita22 - Tuesday, February 27, 2018 - linkHave you got any data to back up those claims?