How Do We Get To Full Throttle In Mobile?

CPU demands are going up at a time when smart phones are getting thinner and the thermal ceiling is lower.

popularity

By Govind Wathan and Brian Fuller

With each new generation of mobile device, we look forward to running the latest apps—especially games. (It’s amazing how immersive mobile games have become in just a few years).

We’re consumers but we’re also engineers, and here we’re faced with a huge challenge. It’s not just the games that get more powerful. A whole new generation of virtual reality apps, sensor-based apps, video and photo editing software is putting new demands on the performance of our phones. This would be easy enough if we could just go full-throttle with CPUs during peak performance, because applications are getting more sophisticated and CPU-hungry. But at the same time, smart phones are getting thinner. An HTC Nexus One, circa 2010, was 11.5mm thick. A 2016 Mate 8 is 7.9mm thick! So getting to, and sustaining, peak performance is an incredible design challenge today because the thermal ceiling is lower.

User experience

This isn’t just an academic or engineering exercise. So much of the success of a smart phone today is tied to user experience. If we play our favorite mobile games hard for 20 minutes and the phone’s temperature rises to the point where the CPU gets throttled to manage the thermal—or the phone consumes too much power and enters power saving mode to conserve battery—we end up with a suboptimal experience.

Outside of these potential issues, the user experience is affected by response times. Response time is measured based on the speed (or latency) to complete a task. It is dependent on the performance of the CPU. (As users, we expect better response time with each new smart phone generation, don’t we?).

Examples of response time critical tasks include launching an application and multi-touch gestures, such as pinch-to-zoom and page-scrolling. For the latter, the proliferation of Web-based applications on Android means that single-thread workloads such as HTML5 and JavaScript are now becoming more prevalent. These trends demonstrate a growing need for high CPU performance and higher frequencies. Relying on frequency alone can be difficult due to thermal throttling. An increase in device temperature may lead to a drastic reduction in the SoC’s available power budget, causing the CPU frequency to drop, as shown in the graph below. The lowering of frequency affects the perceived user experience. That’s obviously not good for the user, and it’s not good for us as engineers.

We started addressing this when we introduced big.LITTLE. With big.LITTLE, system architects assign low-intensity and often long-running threads (for example system tasks and Web workers) onto the higher-efficiency “LITTLE” cores. These types of threads are in the majority when running real-world applications. The “big” cores are then used almost exclusively for high-intensity tasks.

With the introduction last month of the Cortex-A73 CPU, silicon providers drive straight to the heart of sustained peak performance and thermal throttling. Look at the following chart.

ARM1

The example above is based on a system running Cortex-A57 and Cortex-A53. The Cortex-A73 consumes about 30% less power than Cortex-A72 at the same performance (see graph below). This translates to a 50% reduction in consumed power under Cortex-A73 than Cortex-A57. Because power is directly proportional to the amount of heat generated, the Cortex-A73 is a more thermally efficient CPU than the Cortex-A57. To be precise, it is in fact the most thermally efficient high-performance Cortex-A CPU. Going back to the example above and assuming we were using a system running on Cortex-A73 instead, you can expect to see that the Cortex-A73 will remain at a similar frequency in both the “normal operation” and “thermally saturated” ranges, delivering higher sustained levels of performance, and thus a better user experience.

ARM2

Benefits of big.LITTLE
While Cortex-A73 reduces power, big.LITTLE allows for better user experiences compared to symmetric multi-processing systems, (i.e. a system composed only of Cortex-A73 CPUs) by further improving sustained performance and battery life. Knowing the LITTLE CPUs are available to handle the lower-performance range allows chip designers to push the Cortex-A73 CPU to higher frequencies. Higher frequency and static power are traded off against one another in chip design.

At high frequency, static power is a smaller contributor than dynamic power. At low frequencies, static power dominates. Because the low frequency ranges are handled by the LITTLE cores, chip designers can play that tradeoff more effectively toward high frequency without compromising CPU power at the low end of the range. This results in higher highs and lower lows — higher levels of single-thread and multi-thread performance, ultimately delivering enhanced response times and battery life. The release of Cortex-A73 will be closely followed by an update to the big.LITTLE software in the form of Energy Aware Scheduling (EAS), which brings new features and functionality to the way tasks are migrated between big.LITTLE CPUs.

Cortex-A73 based big.LITTLE SoCs will begin to ship in devices soon, bringing a new wave of premium features to your next smartphone device; and along with big.LITTLE, bringing richer, fuller and more satisfying experiences. Do look out for more updates on Cortex-A73 and big.LITTLE in our upcoming blogs.

Engineering is forever a wonderful struggle between wants, needs and what is possible at a given time in history. For engineers, consumers are always a challenging audience to design to. The successes that we’ve delivered have left consumers, throughout the 25 years of the mobile revolution, expecting and demanding more and the user experience is now paramount to consumers. That puts enormous pressure on design teams, but fortunately approaches such as big.LITTLE and Cortex-A73 can take the challenge head-on as CPU performance and efficiency continue to evolve.

—Govind Wathan is product manager at ARM.



Leave a Reply


(Note: This name will be displayed publicly)