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

  • Filiprino - Saturday, July 5, 2014 - link

    You'd be amazed on how can evolve a compiler in development stage.
    Most of the performance advantage from ART comes from AOT compilation. It can take the whole code and optimize it agressively. For example, when compiling GCC with the fastest optimizations you can get the whole program executing in the main function, with loop unrollings and vectorizations while taking into account the difference of having the functions inlined, optimizing references to variables and parameter passing.

    A JIT can only focus on the "hot spots", improving some parts of the program but it can't improve it as a whole because there's not enough performance history storage space to achieve that.

    Then, you've got the new Garbage Collection algorithms which improve interactivity quite a lot.
    Reply
  • seoagile - Thursday, July 3, 2014 - link

    thanks for information. Reply
  • darwinosx - Thursday, July 3, 2014 - link

    So many incorrect statements about jvms in this article it would take a half hour to list them all. Plus nothing at all was said about Googles major motivator which is it is obvious Dalvik was stolen from Sun and the lawsuits aren't over. Finally this is still a long way from true 64 bit and it's benefits. For example the only reason Apple can encrypt and decrypt fingerprints in real time is because encryption operations are dramatically faster in 64 bit.
    Way beneath Anandtech standards.
    Reply
  • grahaman27 - Saturday, July 5, 2014 - link

    You are correct about apple's decision to use 64bit was partly because of the fingerprint scanner, but you are wrong that L is not fully 64bit compatible. In fact, it is easier for android to move to 64 bit because of the VM it runs on. The Linux kernel has always supported 64bit, but Google's runtime and libraries have not, and consequntly neither have the apps. Android L replaces the libraries and runtime with 64bit compatible versions and "enables" 64bit support for 85% of apps automatically with no work from the developers. That's pretty impressive. Reply
  • PearlCParks - Thursday, July 3, 2014 - link

    Contrary to other mobile platforms such as iOS, Windows or Tizen, whjich run software compiled natively to their specific hardwware architecture, the majority of Android software is based around a generic code language whicjh is transformed from “byte-code” into native insstructions for the hardware on the device itself. The performance gains over Dalvik are significant num.to/427-837-276-945 Reply
  • PearlCParks - Thursday, July 3, 2014 - link

    Contrary to other mobile platforms such as iOS, Windows or Tizen, whjich run software compiled natively to their specific hardwware architecture, the majority of Android software is based around a generic code language whicjh is transformed from “byte-code” into native insstructions for the hardware on the device itself. The performance gains over Dalvik are significant http://num.to/427-837-276-945 Reply
  • Filiprino - Saturday, July 5, 2014 - link

    <i>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.</i>
    This feature was implemented in JDK6. Google just imported it into their new VM once ARMv8 (ARM 64 bit) has become available.
    Still, 64 bit android applications will use more memory, if they're compiled by ART for 64 bits.
    Reply
  • Filiprino - Saturday, July 5, 2014 - link

    But that will probably be outweighted by this:

    Because ART compiles an ELF executable, the kernel is now able to handle page handling of code pages - this results in possibly much better memory management, and less memory usage too. I’m curious what the effect of KSM (Kernel same-page merging) has on ART, it’s definitely something to keep an eye on.

    Also, the work won't end with this release. Like Dalvik before, ART will be improved as time goes by.
    Reply
  • editorsorgtfo - Monday, July 7, 2014 - link

    "vast increases in available storage space on today’s devices"
    Oh, you mean the vast increase to 16 GB on the Galaxy S5, the same as my iPhone 3GS from 2009?
    Reply
  • LetsGo - Wednesday, July 9, 2014 - link

    You do know Samsung Galaxy S5 has an memory slot that can handle 128GB cards.

    Thought not You're a Apple user.
    Reply

Log in

Don't have an account? Sign up now