Android performance boosted 30-100 percent by Linaro toolchain

The CyanogenMod project and Google's AOSP are merging the Linaro improvements.

Linaro’s efforts have boosted Android’s performance, delivering an improvement of 30 to 100 percent in various benchmarks. They achieved these impressive gains by adapting Android 4 so that it could be built with their improved GCC toolchain.

We first wrote about Linaro in 2010 when the non-profit organization was founded by a consortium of hardware and software companies, including ARM, Samsung, TI, and Canonical. Linaro has worked to improve the quality of Linux on the ARM architecture, focusing largely on hardware-enablement and tooling.

The group is closely aligned with Ubuntu, but the improvements that it is driving offer benefits for the broader ecosystem of platforms and distributions that are deployed on ARM hardware. They have done a lot of work upstream in GCC (the GNU Compiler Collection) to open the door for better ARM optimization in Linux and other open source software.

As a recent blog post at Liliputing pointed out, Linaro improvements are being merged in Cyanogen, a popular third-party ROM that is maintained through a community-driven process. Enthusiasts have already started generating device-specific builds that incorporated the Linaro patches. A Linaro build for the Galaxy Nexus, for example, was published this week on reddit (disclosure: reddit is a cousin site of Ars).

If you are looking for more information about Linaro, or want to get involved, you can find out more by visiting the organization’s website or checking out the Linaro projects that are hosted on the Launchpad collaboration site.

Update: updated to indicate that Google is merging the improvements, based on a Google+ comment made by Google engineer Jean-Baptiste Queru.

Promoted Comments

Linaro’s GCC improvements have been producing measurable performance advantages over Google’s stock Android environment and build toolchain since late last year. Google is reportedly accepting some of these improvements in the upstream Android Open Source Project and independent developers are also looking to put them to use.

If you're looking for a source for those reports, heres the link to the gerrit pages:

AOKP ROM developer, romanbb, has voiced his opinion on this (also has provided test builds for Galaxy Nexus):

"... I'm personally not sold on the whole thing (although it's definitely fun messing wit hit) and I don't think people really understand what the linaro builds actually do. They don't inject butter into Android. They use a newer toolchain to compile the code (which has more optimizations), and introduce changes into the code which allow the code to use -O3 (another compiler flag to further optimize the code)."

I personally have not seen any significant boost but have seen a big increase in battery life. Some UI interactions seem faster, but I can't think of a way to prove it. Take that with a grain of salt though because I just had my phone replaced. The test builds can be found on RootzWiki if anyone wanted to try it out, but be aware that there are issues being reported with GPS and some apps being incompatible.

AOKP ROM developer, romanbb, has voiced his opinion on this (also has provided test builds for Galaxy Nexus):

"... I'm personally not sold on the whole thing (although it's definitely fun messing wit hit) and I don't think people really understand what the linaro builds actually do. They don't inject butter into Android. They use a newer toolchain to compile the code (which has more optimizations), and introduce changes into the code which allow the code to use -O3 (another compiler flag to further optimize the code)."

Thats not entirely correct. If you look at their patches, they do update the gcc version and fix a lot of bugs enabling more optimization by gcc, but they also introduce NEON optimized library functions:

If you want to know more, see the comments by Bernhard Rosenkraenzer here:

So its really a combination of a lot of bug fixes to the android source as well as new assembly optimizations that speed up existing functions. Actually, when you dig into it Android is somewhat of a mess for an embedded project. You'd think they'd at least have paid ARM to contribute some optimized c library code!

Linaro’s GCC improvements have been producing measurable performance advantages over Google’s stock Android environment and build toolchain since late last year. Google is reportedly accepting some of these improvements in the upstream Android Open Source Project and independent developers are also looking to put them to use.

If you're looking for a source for those reports, heres the link to the gerrit pages:

Does "Google is merging the improvements" mean there will be an ICS update for current tablets or is it intended for the next major OS update?

Everything committed so far has been into the ICS branch, so unless they pulled it for some reason it'd be in 4.0.5 and onward. However, so far, its just been fixes for code problems like aliased pointers and gcc weirdness, not performance enhancements. Depending on how fast they move, that might or might not be ready for the next point release.

In the meantime, a lot of this work has already been incorporated into cyanogenmod, so that will certainly be in 4.0.4 based releases, although perhaps not all of it depending on how quickly issues can be worked out.

Been running this since yesterday. Not sure if it was a fluke, but while I was traveling through Nashville, TN using the GPS to navigate, it suddenly started telling me to turn on Peachtree St... Atlanta, GA. Exited out of the app, restarted and everything was fine. Was a weird moment though!

Considering Apple is likely putting a ton of effort into LLVM for ARM, would that not be an interesting test? Or is there some NIH syndrome in the Android camp with compilers other than gcc? Or does android just not build using anything but gcc?

Pity this can't be forced onto handset makers . Be great for lower end hardware, right? Make more affordable hardware run like you had an upgrade, yeah?

Low end devices generally don't have NEON, and some of the rest is A9 specific. So its probably a lot less useful for older hardware. Actually, Tegra 2 doesn't have NEON either, so newer stuff like the Motorola zoom is probably not going to get as much out of it.

I think its a mistake to assume that this is going to make everything 30% faster. Its making some library functions faster, and some libraries better optimized by the compiler. If you're doing a lot of memcpy and memset, then yes this will be a lot faster. If you're sitting around waiting for some java library or your graphics driver to render a frame, then no this is much less important. How much this matters in general, I have no idea. I wouldn't be surprised if some of the OEMs out there may have realized that optimizing low hanging fruit like the compiler libraries (or even just licensing proprietary ones) is a great way to make their devices feel faster without spending a lot of money, so some people may be running similar stuff already in stock ROMs.

Its probably better to think of this as the latest of a long series of improvements by the community and by businesses that bring Android (and to an extent linux and open source in general) on ARM closer to parity with x86 linux after many years of relative neglect.

I don't know about the Android team, but a lot of people are really interested in LLVM, since its a great compiler and historically gcc hasn't been so awesome on ARM, but at the moment it doesn't seem to be quite there yet.

Edit:

sporkme wrote:

Or is there some NIH syndrome in the Android camp with compilers other than gcc?

Since renderscript on android is already LLVM based, I don't think they're opposed to LLVM in general. But yeah, linux in general tends to lean gcc for obvious reasons.

I really can't take Phoronix seriously. Larabel is good at being a click-whore and that's about it. This was published on 6/11 and he's using 3.0 even though 3.1 is available (and I believe 3.2 is out for testing). I know little about LLVM other than I need to know quite a bit more about it as it will be the default compiler on a bunch of boxes I take care of shortly. But even with my limited knowledge, I can pretty much guarantee the newer version is going to be faster than what he tested.

This is also without knowing whether he's even benchmarking tasks that are relevant to a mobile OS.

This is the genius that tests ZFS on a laptop and pronounces it "slow".

redleader wrote:

I don't know about the Android team, but a lot of people are really interested in LLVM, since its a great compiler and historically gcc hasn't been so awesome on ARM, but at the moment it doesn't seem to be quite there yet.

I really can't take Phoronix seriously. Larabel is good at being a click-whore and that's about it. This was published on 6/11 and he's using 3.0 even though 3.1 is available (and I believe 3.2 is out for testing).

I don't know anything about that author, but seeing as 3.1 came out 3 weeks ago and they have a 6 month release cycle, I don't think 3.2 is out for a while yet. Anyway, it looks like that comparison is a redo of an article from a month ago, I'm guessing a lot of it is from before that release, hence the 3.0 release.

sporkme wrote:

redleader wrote:

I don't know about the Android team, but a lot of people are really interested in LLVM, since its a great compiler and historically gcc hasn't been so awesome on ARM, but at the moment it doesn't seem to be quite there yet.

Has Apple actually said what they use to build iOS? I'd be interested in reading about what compilers are used. I just assumed it was like on the old iPod OS where it was a mishmash of different compilers depending on what was faster/easier for different libraries. Not like Android where you want third parties rolling their own builds and thus have to keep the build system more manageable.

Pity this can't be forced onto handset makers . Be great for lower end hardware, right? Make more affordable hardware run like you had an upgrade, yeah?

Low end devices generally don't have NEON, and some of the rest is A9 specific. So its probably a lot less useful for older hardware. Actually, Tegra 2 doesn't have NEON either, so newer stuff like the Motorola zoom is probably not going to get as much out of it.

I think its a mistake to assume that this is going to make everything 30% faster. Its making some library functions faster, and some libraries better optimized by the compiler. If you're doing a lot of memcpy and memset, then yes this will be a lot faster. If you're sitting around waiting for some java library or your graphics driver to render a frame, then no this is much less important. How much this matters in general, I have no idea. I wouldn't be surprised if some of the OEMs out there may have realized that optimizing low hanging fruit like the compiler libraries (or even just licensing proprietary ones) is a great way to make their devices feel faster without spending a lot of money, so some people may be running similar stuff already in stock ROMs.

Its probably better to think of this as the latest of a long series of improvements by the community and by businesses that bring Android (and to an extent linux and open source in general) on ARM closer to parity with x86 linux after many years of relative neglect.

So from what i gather, this is not really that much different than what we see in compiling for i686 vs i386 on a desktop Linux distro? With the former allowing the use of MMX and other nifty stuff that has been introduced on the x86 CPU front since 386 was not stuff.

The last update Google pushed definitely improved the responsiveness of my GN. The most significant improvement was closing the applications. Before the update when I pressed the "Show Apps" and tried to close the app immediately it would not respond. However, after the update, the damn thing is fast. I would love to try this build, but probably wait for Google to integrate the enhancements and get updates directly from them.

They managed to get some serious performance boosts, particularly in areas related to structs and generics (which doesn't surprise).

Not that we'll ever see it on a device, but it's an interesting exercise nonetheless.

Interesting news...

Mono might be a tad too heavy for smartphones, but I can see it totally suitable for large-ish tablets and lightweight computers.

C#/Mono and Java/Dalvik are both in the same ballpark in resource needs. If the windows 7 phone is any indication C#/mono can easily be made lighter than Java/Dalvik, with a similar level of functionality.

somewhat tangential - I'd be interested to see if the pretty impressive performance than Intel managed in their x86 Android phone is due to GCC (or even ICC - I don't know which they're using) just being better at compiling for x86..

I appreciate your desire to make disclaimers about referencing "sister" or "cousin" websites, but could you do so through a footnote/endnote instead of in parenthesees in the main body of the article? It's just a little distracting. Thanks!

So what guarantee can be offered, that will allay the fears of Back Door code being introduced, as has beensuggested, exists in Android O.S.As a side issue, does anyone know of how a check can be made, on the ARM microcode, to verify itspurity?