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.

Conclusion

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
POST A COMMENT

137 Comments

View All Comments

  • moh.moh - Wednesday, July 2, 2014 - link

    Can somebody confirm or deny that the ART from KitKat is the same as the ART from L? What I have read points to ART from Kitkat being different from ART on L. Reply
  • p3ngwin1 - Wednesday, July 2, 2014 - link

    ART in the existing Preview release of "L" already is more advanced than KitKat's.

    the final release of ART on "L" will be even more changed than the current Preview of "L".
    Reply
  • phoenix_rizzen - Wednesday, July 2, 2014 - link

    Yeah, it's an evolutionary upgrade, not a revolutionary whole-hog replacement.

    Just as Dalvik in 4.4 is different from Dalvik in 2.3; it's an evolutionary upgrade.
    Reply
  • tipoo - Thursday, July 3, 2014 - link

    The current build of L is more developed and better performing with ART than Kitkat, as will the final be. Reply
  • raghu.ncstate - Wednesday, July 2, 2014 - link

    "Google was not happy with this and introduced a new memory allocator in the Linux kernel, replacing the currently used “malloc” allocator" - Malloc allocator is not in the kernel. I dont think there was any change to the linux kernel in this. Malloc and Rosalloc are both done in user space in the ART lib. Both probably use the sbrk() system call to get memory from the kernel. Also a quick look at Rosalloc.cc code shows it is written in C++. So definitely cannot be in the linux Kernel. Reply
  • 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 ;-) Reply
  • 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.
    Reply
  • 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. Reply
  • 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. Reply
  • 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. Reply

Log in

Don't have an account? Sign up now