Does a multithreaded browser use more power?

In previous posts I’ve talked a lot about our Flow browser’s ability to use all the cores and the GPU in a modern SoC to get better performance. There is question about whether it is a good idea to use all the cores in battery operated devices. The reasoning being that a quad core processor would use more power if all the cores were fully loaded and as multithreaded performance gains aren’t linear, then surely power must be being wasted.

I looked into published SoC power consumption data and the theory behind power management which showed this is not necessarily the case. Indeed, it suggests that Flow could offer savings in power consumption which would, in turn, help with heat management in very small form factor devices like dongles and wearables.

Modern SoCs cleverly manage the voltage and frequency of the cores to deliver the required performance with minimal power consumption, originally by turning off unused cores. The spin up time for an idle core impacts performance, so there is a trend away from this towards keeping unused cores at a lower ‘not quite idle’ state. This trades power consumption for microsecond spin up response times.

In addition to these power management features, product manufacturers select the frequency and internal voltage that the SoC operates at. Where a trade of performance for power consumption is needed, designers can lower the SoC frequency and use a lower internal voltage, together these deliver significant power savings (P∝ V² x f). Further savings are made with each reduction in SoC process size, so in general newer devices are more power efficient than older ones. Because power consumption and heat dissipation are often concerns, modern SoCs are normally used and, for mid/high performance applications, that almost always means a multicore device.

As I discussed in previous blogs, for single page display and application rendering, traditional browsers really only use one core and that means that the single core performance has to be sufficient to deliver an acceptable customer experience. Whilst there are other software components that also need to use the processor, most of the time, over half of the multicore SoC lies in the ‘not quite idle’ state – using power but delivering no benefit.

Flow on the other hand uses all of the cores meaning that it’s the overall SoC performance, rather than the single core performance, that matters. Using Flow, product designers can achieve the same acceptable performance at a lower operating frequency and in many cases, they can use a lower performance SoC without sacrificing the user experience.

Detailed power consumption graphs are not usually published by the SoC providers, but using data on the Samsung Exynos 7420 that Andrei Frumusanu published in 2015, I can quantify what I mean. The Exynos 7420 has both medium and high performance cores which allows us to see when a traditional browser would need to use the higher performance cores whilst Flow can deliver the same performance from the medium performance, less power hungry, ones.

I’ve coined the term ‘productive DMIPS’ to mean the processing power that is actually used by the browser for productive work. For a traditional browser, only one core is useable so productive DMIPS are approximately equal to headline DMIPS divided by the number of cores. With Flow all the cores are useable but, as the performance gains aren’t linear, the productive DMIPS are less than simply taking the headline DMIPS number.

The graph below shows the power consumption per productive DMIPS on the Samsung Exynos 7420. To get a given user experience at the optimal power consumption, a traditional browser would have to use the faster cores for anything above 2,500 DMIPS. With Flow, the slower cores continue to deliver the given user experience at optimal power consumption all the way up to 6,500 DMIPS.

Taking a scenario where a high end application needs 8,500 DMIPS, a traditional browser based app would consume 1620mW. Using all the cores, the same application running on Flow could provide the same user experience with just 1030mW. In this example the power saving is just over 36% – or in wearable terms, four days between re-charges rather than three.

Circling back, the original question was whether it is a good idea to use all the cores. As Flow’s clever core usage can achieve the same user experience at a much lower operating frequency, there is considerable scope for power savings and, in turn, heat management. Granted, I have only focused on the CPU power consumption and not that of the GPU, but the data certainly suggests that Flow is ideal for very small form factor devices like dongles and wearables.