You don’t need to make a parallelized, multicore app in every instance of mobile development. But sometimes you should make the extra effort.
In my previous story, I discussed the situations where a multicore processor could actually be a detriment to the phone and unnecessary to the developer. The article was inspired by a white paper from ST Ericsson on two topics: multi-processors in mobile platforms and FD-SOI or Fully-Depeleted Silicon-on-Insulator.
In this article, I present the other side of the coin: why multicore processors are a good thing for your smartphone, even if they drain a battery faster.
ARM Holdings (which pretty much owns the mobile market) argues that multicore has value. And that starts with solid core design, says James Bruce, ARM’s lead mobile strategist.
To reduce power consumption as much as possible, ARM, and Intel as well, have focused extensively on core switching and electronic gates to power down cores when not in use.
Intel is up to quad-core Atoms with its Bay Trail generation, but ARM is doing one better, going eight-core with its big.LITTLE design, Bruce explains. In big.LITTLE, four fast, high-performance cores are paired with four slower, lower-performance cores. Each process is assigned to a core depending on what it needs. If it needs a lot of processing power, it goes to the fast core. If the process doesn’t need much horsepower, it goes to a slower core.
“big.LITTLE is less about the fact that it has eight cores, but rather it addresses the fundamental problem with processors, which is that the higher performance you achieve, the more inefficient cores typically become. The sophisticated power management in a big.LITTLE utilizes the low-power cores as much as possible and the higher-performance cores are only leveraged when the user is doing something really demanding,” says Bruce.
Beyond that, though, there are no significant differences between multicore on PCs and multicore on mobile devices, argues Will MacKay, lead developer with ACME AtronOmatic, which makes a multiplatform app called MyRadar.
“Multicore development is only viable and preferable when the app’s performance is unsatisfactory,” he says. “One common problem is an app freezing up while it completes some task. Running such a task in a background thread allows the app to remain responsive while the task is in progress.”
However, this complicates development, because by the time the task finishes, the user might have navigated elsewhere or changed some option. So the app may need to cancel the task or redo it.
“The number of possible scenarios is much larger when you allow the user to continue interacting with the app, and the developer must handle each of these scenarios explicitly. It is difficult to anticipate them all, and to test them all,” says MacKay.
On the software side, Bruce says, HTML5 is a small segment of the application population and the vast majority of mobile apps are compiled C code. “There are very few applications for mobile that are HTML5. The fact of the matter is that most Android applications are native and written in C or C++. Also, many apps are written in Java and then converted for Dalvik, which is the multithreaded software that runs apps on Android devices,” he notes.
For a while, it seemed like HTML5 would take over the world. Steve Jobs declared Adobe Flash dead in favor of HTML5 while Microsoft abandoned its own Silverlight technology. At the 2011 Build conference, Microsoft sang repeated praises to HTML5.
The decision of HTML vs. compiled apps often comes down to development cost. “An HTML app is cheap to develop because it doesn’t take long and because HTML developers are more common and charge less,” says MacKay. “However, HTML doesn’t have as much flexibility; the design must be simple. If the UI is complex enough, a native app is the only way to produce it.”
And HTML5 isn’t the panacea it was sold as. “Everyone points to HTML5 as a way of building once and running on every device, but it doesn’t work that way because HTML5 is the least common denominator approach. What happens when a device has a driver HTML5 doesn’t support? You have to go back to native code. So native code isn’t going away any time soon,” says Jack Gold of J.Gold Associates, a mobile technology consultancy.
The real problem is talent and tools. Multicore apps are more expensive to develop because they take longer, and capable developers are rare and charge more, says MacKay. Plus, he adds, “At this point, the tools for parallelizing code are terrible. Apple and Microsoft have both been working on this but the improvements are marginal, nothing revolutionary.”
ARM’s Bruce agreed. “HTML5 tools are still evolving, so depending on the type of application being developed, the tools may not be as fully developed.”
After rushing to embrace HTML5, both Facebook and LinkedIn dumped it, returning to compiled mobile apps. Facebook boss Mark Zuckerberg said his company made a mistake in betting on HTML5 over native apps. LinkedIn also dumped HTML5, again saying that the tools are lacking.
In the end, HTML5 is still a markup language and not native code and subject to limitations. There is the parallel.js library for multicore and parallel programming, but it can’t beat native code for that purpose.
On a smartphone or tablet, multicore is most valuable if you are developing games, which admittedly is one of the most popular reasons people have for owning these devices. You need a multicore situation to play Angry Birds while waiting for an oil change, but not to check your mail.
So while I went looking for reasons to support the premise that multicore really does matter for mobile app development, I found few active developers who were ready to nod in agreement. Do you see things differently? I’d love to hear about it in the comments.