64-Bit Support

ART was designed in mind with modularity of the various target architectures in which it is supposed to run on. As such, it provides a multitude of compiler-backends targeting today’s most common architectures such as ARM, x86 and MIPS. In addition, 64-bit support for ARM64, x86-64 and while still not implemented, also MIPS64.

While we have gone more in depth of the advantages and implications of switching over to 64-bit architectures in the iPhone 5s review, the main points to take away are the availability of an increased address space, generally increased performance, and vastly increased cryptographic capabilities and performance, all while maintaining full 32-bit compatibility with all existing apps.

An important difference that Google is applying over Apple, at least inside VM runtime applications, is that they are using reference compression to avoid the usual memory bloat that comes with the switch to 64-bit. The VM retains simple 32-bit references.

Google has made available some preview benchmarks showcasing the performance gains both on x86 and ARM platforms. The x86 benchmarks were executed on a Intel BayTrail system, and show a 2x to 4.5x speedup in various RenderScript benchmarks. On the ARM side, the crypto performance gains over 32-bit were showcased on an A57/A53 system. Both of these are relatively non-representative of one should really expect in real-world use-cases so they’re not that useful as a performance prediction.

However Google also made some interesting numbers available on one of their internal build-systems called Panorama. Here we can see a 13 to 19% increase in performance by simply switching over the ABI. It is also good to see how ARM’s Cortex A53 is able to make a bigger impact on performance when in AArch64 mode than the A57 cores.

Google claims that 85% of all current Play Store apps are immediately ready to switch over to 64 bit - which would mean that only 15% of applications have some kind of native code that needs targeted recompiling by the developer to make use of 64-bit architectures. This is a great win for Google and I expect the shift over to 64-bit to be very fast once silicon vendors start shipping 64-bit SoCs in the coming year.


In many points, Google has delivered its “Performance boosting thing” and addressed much of the shortcomings that have plagued Android for years.

ART patches up many of the Achilles’ heels that comes with running non-native applications and having an automatic memory management system. As a developer, I couldn’t have asked for more, and most performance issues that I needed to work around with clever programming no longer pose such a drastic problem anymore.

This also means that Android is finally able to compete with iOS in terms of application fluidity and performance, a big win for the consumer.

Google still promises to evolve ART in the future and its current state is definitely not what it was 6 months ago, and definitely not what it will be once the L release is made available in its final form in devices. The future looks bright and I can’t wait to see what Google will do with its new runtime.

Garbage Collection: Theory and Practice
Comments Locked


View All Comments

  • jospoortvliet - Thursday, July 3, 2014 - link

    On that C++ point - Linus has been coding C++ - http://liveblue.wordpress.com/2013/11/28/subsurfac... so who knows what the future holds ;-)
  • Haravikk - Wednesday, July 2, 2014 - link

    The article mentions that startup times for devices will be worse with ART, but I don't understand why; surely if the code has already been compiled it will simply be cached somewhere, so it's just a case of executing it directly. In fact, this should mean that startup should be faster than normal.

    In fact, the space requirement is another question mark; once an application has been compiled, does the byte code even need to be retained? Surely it can be discarded in that case? Though I suppose it's required to ensure that signatures don't change, it seems like the OS could enforce that differently (i.e - as long the byte code validated pre-compilation, then the compiled code is considered signed as well)?

    I dunno, it just seems to me like there are plenty of ways to not only avoid slow-downs or extra storage use, but in fact there are ways to use ahead of time compilation to accelerate startup and reduce storage use.
  • Stochastic - Wednesday, July 2, 2014 - link

    I think you're correct. First time device startup and app installations will be longer, but once the compilation is done startup times shouldn't be slower.
  • metayoshi - Wednesday, July 2, 2014 - link

    It only makes sense the the application's first startup will take a long time. That first startup is where the Ahead of Time compilation is happening. Where else would it happen? Application startups after that will be much quicker, though, since the AOT compilation was already done beforehand.
  • phoenix_rizzen - Wednesday, July 2, 2014 - link

    AoT happens when the app is installed on the phone; or during the first boot after changing the runtime to ART.
  • hahmed330 - Wednesday, July 2, 2014 - link

    One Stone... Three birds...
  • Notmyusualid - Wednesday, July 2, 2014 - link

    Just switched my GS5 over to Art, from Dalvik, and Antutu result dropped by 8%...

    Yes, the choice is on the stock ROM, just goto developer options, and select runtime.
  • tuxRoller - Thursday, July 3, 2014 - link

    Use ANY other benchmark. Who the hell knows how antutu works?
    For micro benchmarks try geekbench.
    If you're willing to do some compiling, linaro has a bunch of benchmarks it uses to determine progress.
  • Notmyusualid - Thursday, July 3, 2014 - link

    Call me crazy, but I don't pay for apps....

    I take only the free ones.

    I see no free Geekbench on the Play Store.
  • tuxRoller - Friday, July 4, 2014 - link

    I didn't realize you had to pay for it.
    Regardless, antutu is junk. Why? Because we don't know exactly what it does, or how it does it.
    The other option I mentioned is pick some of the linaro benchmark tools and compile them.
    I won't call you crazy for not buying apps because I don't know your situation. What I do, however, is try free versions and if they are good I buy them. They don't cost much and I don't waste battery with ads I'll ignore.

Log in

Don't have an account? Sign up now