Conclusion

Samsung's System LSI business had a rough two years as their decision to go with ARM's big.LITTLE SoC architecture cost them a lot of market share, thanks in part to immature software and implementation issues. Usually in the past Samsung's own Exynos SoCs were regarded as the more performant variant given the choice of Qualcomm's Scorpion CPU based solutions. This changed as the Exynos 5410 came out with a malfunctioning CCI, crippling the chip to the most battery inefficient operating mode of big.LITTLE.

Qualcomm's Snapdragon 800 capitalized on the new 28nm HPM manufacturing process, along with the advantage of being able to offer an integrated modem solution, and has dominated the market ever since. It's only now that Samsung is able to recover as the new 20nm manufacturing process allowed them to catch up and start to offer their own Exynos SoC in more variants of its products, a trend that I expect to continue in Samsung's future lineup.

The Note 4 with the Exynos 5433 is the first of a new generation, taking advantage of ARM's new ARMv8 cores. On the CPU side, there's no contest. The A53 and A57 architectures don't hold back in terms of performance, and routinely outperform the Snapdragon 805 by a considerable amount. This gap could even widen as the ecosystem adopts ARMv8 native applications and if Samsung decides to update the phone's software to an AArch64 stack. I still think the A57 is a tad too power hungry in this device, but as long as thermal management is able keep the phone's temperatures in reign, which it seems that it does, there's no real disadvantage to running them at such high clocks. The question is whether efficiency is where it should be. ARM promises that we'll be seeing much improved numbers in the future as licensees get more experience with the IP, something which we're looking forward to test.

On the GPU side, things are not as clear. The Mali T760 made a lot of advancements towards trying to catch up with the Adreno 420 but stopped just short of achieving that, leaving the Qualcomm chip a very small advantage. I still find it surprising that the Mali T760 is able to keep up at all while having only half the available memory bandwidth; things will get interesting once LPDDR4 devices come in the next few months to equalize things again between competing SoCs. Also ARM surprised us with quite a boost of GPU driver efficiency, something I didn't expect and which may have real-world performance implications that we might not see in our synthetic benchmarks.

It's the battery life aspect that I think it's most disappointing to me. It's a pity that Samsung didn't go through more effort to optimize the software stack in this regard. When you are able to take advantage of vertical integration and posses multi-billion dollar semiconductor manufacturing plants with what seem to be talented SoC design teams, it's critical to not skimp out on software. I might be a bit harsh here given that the battery disadvantage was just 12% in our web-browsing test and might be less in real-world usage, and the GPU battery efficiency seems neck-and-neck. Still, it's the wasted potential from a purely technical perspective that is disheartening.

This is definitely a wake-up call to ARM and their partners as well. If the software situation of big.LITTLE isn't improved soon I'm fearing that ship will have sailed away, as both Samsung and Qualcomm are working on their custom ARMv8 cores.

So the question is, is it still worth to try and get an Exynos variant over the Snapdragon one? I definitely think so. In everyday usage the Exynos variant is faster. The small battery disadvantage is more than outweighed by the increased performance of the new ARM cores.

Battery Life & Charge Time
Comments Locked

135 Comments

View All Comments

  • aryonoco - Wednesday, February 11, 2015 - link

    Everyone is aware that developing a power-aware scheduler is a VERY hard problem. The Linux kernel doesn't have it, but neither does anyone else really.

    The problem is that when ARM developed big.LITTLE, they would have known that for it to work, it requires a well-designed power-aware scheduler. And they should have known that that's a very hard problem to solve in software. History is littered with great hardware architectures that should have performed a lot better, if only the software was up to it, e.g., Intel's Itanium or Transmeta's Crusoe. But history has time and time shown that architectures that require too clever a software solution around them just don't work (perhaps one should add AMD's Bulldozer to this list as well, seeming as AMD expected everyone to rewrite their software to become GPU aware).

    I remember back in the days KISS was a big mantra of Unix sysadmins, and for a good reason: you can optimize simple things very well. Witness the simple (by comparison) dual core Apple A8 that doesn't require any magical scheduler or a binary translator (Denver) and yet beats everyone else in practical tests. It's disheartening that the likes of ARM and Nvidia don't seem to have learnt this.
  • tuxRoller - Thursday, February 12, 2015 - link

    The article suggests that this (the scheduler) is work that Samsung (alone) should've done. I don't recall the author indicating that it's actually an unsolved problem in computer science (again, in a general purpose environment), as I indicated, BTW.
    big.LITTLE will certainly work best with such a scheduler, but even without you should expect to approach some efficiency that lies between the big and little cores. Even this half-hearted attempt isn't terribly worse than the android competition.
  • Andrei Frumusanu - Thursday, February 12, 2015 - link

    Power collapse is proper power gating on the individual cores in their respective CPUIdle states, your link is outdated and does not apply to new generation ARM cores.
  • tuxRoller - Thursday, February 12, 2015 - link

    Do you have a reference?
    To the best of my knowledge linaro are still working on hotplug.
    Also, for Linux, cpuidle refers to a specific governor that doesn't actually power down, but handles the c states, but it looks like arm uses it for suspension (http://events.linuxfoundation.org/sites/events/fil... slides 10 and 13).
  • Andrei Frumusanu - Friday, February 13, 2015 - link

    CPUIdle is the kernel framework that manages the CPU's idle states, such as WFI (Clock gating), core power collapse, cluster power collapse. CPUIdle states are C-states, but "C-states" is an ACPI denomination that is rarely used on ARM CPUs.

    Hotplug has been left for dead for a long time, it hasn't been used for PM in ARM CPUs since the A15/A7 generation. Today it's only used for like forcing cores off when in screen-off states or rare coarse power management for like battery savings modes for some vendors.
  • sgmuser - Thursday, February 12, 2015 - link


    I have Exynos and wanted that specifically for the Wolfson Audio. Sad to note that, its not exploited enough by Samsung.

    Did someone notice the RAM bandwidth. How much impact that it makes?
    Also, from personal experience, I find exynos seems to be smooth and never noticed lag for an user like me. Graphics performance could be better but again no visible issues for what I have been playing so far with such dense display.
  • giaf - Saturday, February 14, 2015 - link

    Very interesting and detailed article, thank you.

    I have been working with ARMv7A cores, and I am interested in the floating-point capabilities of new 64-bit ARM processors. What is the throughput of the main floating-point instructions (add, mul, MAC) for Cortex A53 and A57? Something similar to the test done in http://www.anandtech.com/show/6971/exploring-the-f...
  • thegeneral2010 - Wednesday, February 18, 2015 - link

    i just dont get it wat do u mean by "however it remains unclear whether we'll see this on the Note 4. My personal opinion remains that we won't be seeing this overhaul in Samsung's 5.0 Lollipop update." does this mean that exynos 5433 could be upgraded to 64bit on android 5.1 or later updates??
  • Andrei Frumusanu - Friday, February 20, 2015 - link

    At the time of the writing the Lolipop update was not yet released. Now it's out and it's not 64bit as I suspected. If they didn't update it now they won't ever update it and it will stay on AArch32.
  • thegeneral2010 - Sunday, February 22, 2015 - link

    so wat about that official patches in upstream linux?

Log in

Don't have an account? Sign up now