The PC solution for the CPU performance wall was to throw more cores at it. That’s not necessarily the best way to improve mobile app performance.
Several years ago, desktop PCs hit a performance wall. Intel thought that it could keep raising the clock speeds and keep up with the cooling issues, but something happened on the way to 4GHz. That “something” was a heat wall that required a heat sink and fan almost as big as a power supply to keep the CPU cool. Other crazy experiments included liquid cooling, including antifreeze coolant, and even liquid nitrogen.
The trick, then, was to go multicore, and to speed up PCs by dividing the tasks among cores. Windows XP handled multicore technology better than it had any right to, given its age. Windows XP saw a two-core CPU as two CPUs and processes were split accordingly. Microsoft would improve on multicore support in Windows 7.
Of Windows Vista, we shall not speak its name.
As smartphone hardware improved and applications demanded more performance, the situation was almost the same. Manufacturers couldn’t make CPUs any faster because of heat dissipation issues in that tiny space and power drainage. So rather than put a 2GHz CPU in a phone, makers began using 1.2GHz dual core phones. Then came quad-core CPUs, like Nvidia’s Tegra 3 and a few in Qualcomm’s Snapdragon line.
However, the scalability that worked well in the PC (mostly) and better in the server market doesn’t work so great in a smartphone, because the nature of the development environment is completely different animal.
This was originally pointed out in a white paper (PDF) by ST-Ericsson, which notes that on the PC multicore never really caught on for a variety of reasons, and they apply even less on the smartphone.
The reason why software developers don’t parallelize their code, wrote the paper’s authors, is that “For most of the PC applications it is simply not necessary or not economical to do so, with the exception of some niche markets for which performance is a compelling differentiating feature, such as for some multimedia applications, CAD and some specific professional areas.”
When it comes to smartphones, the white paper notes that single core performance isn’t even saturated with current technology, so second cores are hardly necessary. Smartphones are driven by Web browsing and HTML5-based applications, and here, multicore is fairly worthless because HTML5 itself is not multicore.
The conclusion, then, is that smartphone makers are putting far too much processing power in phones, much more than necessary. HTML5 will not use three of the four cores of a Tegra 3 but the cores will draw power.
Smartphone developers working with HTML5 agree on this. “Adding more cores is not necessarily the best way to do it but having enough core processing power is,” said Jason Baptiste, CEO of Onswipe, a developer of custom content apps for handheld devices. Baptiste said he would rather have a tighter integration with the GPU. Cascading Style Sheets 3 (CSS) uses hardware acceleration in the GPU, and that’s much more important to him than four CPU cores.
“Two cores make sense, four is experimental, eight is loony,” said Cameron Laird, vice president of boutique Web consultancy Phase It and frequent author on HTML5 development (including several articles here at SmartBear). He expects that smartphones will eventually be able to utilize two cores. “Current Web browsers tend to be among the hardest common loads for mobile devices, especially to the extent that they do interesting HTML5-that-goes-beyond-HTML4 things. I expect mobile browsers to improve significantly over the next year. Dual-cores will look like clear winners over single-core for Web pages.”
One thing in ARM’s favor, Laird noted, is that it has done a very good job at multicore management, so it can reduce power usage selectively. “That’s a significant win, and it’s at hand,” he said.
“Based on what I’ve read, I would agree that multicore is most likely wasted for HTML5 apps,” said Chris Minnick, president of Minnick Web Services, a mobile website designer. “I know that the biggest problem with HTML5 app performance is with people writing inefficient code. It is possible to write HTML5 code that takes advantage of multicores, by using Web Workers.”
“Very few HTML5 apps are written to take advantage of multicore, because very few HTML5 apps are written with any consideration of the hardware they’ll run on at all. The extra layer of abstraction between a Web app and a device makes it easy to forget or neglect to do this type of performance tuning,” Minnick added.
Baptiste is more concerned with the GPU, both its implementation and integration, than with CPU cores. “Having a great GPU that can leverage HTML5 is where it can really matter. The problem is no one is taking advantage of that on a scale that really matters,” he said. “WebGL takes advantage of the graphics processor, but it’s not used on iOS except in iAds.”
“I’d rather have a much faster GPU and more memory than more cores,” Baptiste said.
Minnick felt the same way. “Yes, for sure, [faster cores over more cores]. A faster GPU would be much more preferable but, again, it’s a trade-off between performance and battery life. I’d rather have better battery life and browsers and Web apps that were better optimized for the hardware,” he said.
- Gelsinger and Meyer: Two CPU Designers Who Changed the World
- Making the Most of GPU Acceleration in Your Web Apps
- What Intel and AMD’s Latest Multicore Development Moves Mean to You