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

  • jabber - Wednesday, July 2, 2014 - link

    Been using ART on my Nexus 4 since Jellybean came out. No issues. Life carries on as normal. Reply
  • Krysto - Wednesday, July 2, 2014 - link

    I can't believe Google hasn't also adopted F2FS in Android L. I would've been perfect. How is it that they put it in Motorola devices a year ago, and they still can't make it default on stock Android? Reply
  • uhuznaa - Wednesday, July 2, 2014 - link

    Because changing the FS in an update sucks. You may see this in new devices, but not in updates for existing devices. Reply
  • phoenix_rizzen - Wednesday, July 2, 2014 - link

    Not really. It just depends on how the update is done.

    If it's a "nuke'n pave" restore (like the Dev Preview or System Images), then it's not an issue. Backup your data to the PC/cloud, reformat all partitions, install, carry on.

    If it's an in-place upgrade, then it becomes tricky. Unless, of course, you are using F2FS for the /data filesystem, which (really) is the only one that benefits from it. You don't need to make /sdcard (internal storage) F2FS, and you don't want to make /ext-sd (SDCard) F2FS as then you lose all non-Linux reader support. Nothing stopping you from using those as F2FS, though.

    I'd really like to get a custom recovery for the G2 that allowed you to select which FS to use for each partition, and a ROM with a kernel that supported it, though. Just to try it out, and see how it works. :) Any takers? ;)
    Reply
  • moh.moh - Wednesday, July 2, 2014 - link

    Yeah, I am really hoping for a big push towards F2FS in the coming months. I mean Moto has showed the significant increase in performance which we can get. Reply
  • Krysto - Wednesday, July 2, 2014 - link

    > but bad programming practices such as overloading the UI thread is something that Android has to deal with on a regular basis.

    I believe they've also added a new UI thread now to L. You should look into that. I think it's in one of Chet Hasse's sessions, possibly in "What's new in Android".

    I think I found it: https://www.youtube.com/watch?v=3TtVsy98ces#t=554
    Reply
  • Krysto - Wednesday, July 2, 2014 - link

    > 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.

    Does this means that OEMs could use soon "pure" Aarch64 architectures? I think you can use ARMv8 purely for the 64-bit mode, with no compatibility for 32-bit, too. I imagine that would make the chips less expensive and also more efficient for OEMs.

    I'm not familiar with how Intel has its chips, but I think it would be a lot harder for Intel to get rid of the "32-bit" parts, and they are pretty much stuck with their chips being both 32-bit and 64-bit, at least for the next few years, until nobody in the world needs 32-bit anymore on any platform Intel chips runs, and then they could just redesign their architecture to be 64-bit only.
    Reply
  • _zenith - Wednesday, July 2, 2014 - link

    x86 also has a 16bit mode AFAIK, so its more complicated than that still. [80]x86 is just a bitch of an ISA. Reply
  • name99 - Wednesday, July 2, 2014 - link

    I've long suggested that this is exactly what Apple will do. I don't think they'll ditch 32-bit support for the A8, but I honestly would not be surprised if the A9 comes without 32-bit support and iOS9 has a 32-bit SW emulator to handle old apps. Then by iOS 11 or so they just ditch the 32-bit emulator.

    Other vendors have the problem that they don't have a tight control over the entire eco-system. Qualcomm, for example, are not making Android chips, they're making ARM chips --- for anyone who wants an ARM chip. It's something of a gamble to just ditch 32-bit compatibility and tell anyone who wants that "Sorry, you should go buy from one of these competitors". Most companies (foolishly, IMHO) weigh the cost of backward compatibility as very low, and the cost of losing a sale (even if it's to a small and dying industry segment) as very high; so I suspect they're not even going to think about such an aggressive move until years after Apple does it.
    Reply
  • coachingjoy - Wednesday, July 2, 2014 - link

    Thanks for the info.
    Nice article.
    Reply

Log in

Don't have an account? Sign up now