A Closer Look at Android RunTime (ART) in Android L
by Andrei Frumusanu on July 1, 2014 7:12 PM EST64-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.
Facebook
Twitter
RSS
136 Comments
View All Comments
Gigaplex - Tuesday, July 1, 2014 - link
"With the latest I/O conference, Google has finally publicly made public"Public, you say?
"Contrary to other mobile platforms such as iOS, Windows or Tizen, which run software compiled natively to their specific hardware architecture, the majority of Android software is based around a generic code language which is transformed from “byte-code” into native instructions for the hardware on the device itself."
Windows has a fair amount of .NET.
jeffkibuule - Tuesday, July 1, 2014 - link
I was about to make that comment but learned that at least for Windows Phone 8, it's not true. It uses a cloud compiler: http://www.reddit.com/r/programming/comments/1njas...Gigaplex - Tuesday, July 1, 2014 - link
I wasn't aware of that, thanks for the link. Windows Phone 8 isn't strictly the only Windows mobile platform though.tipoo - Thursday, July 3, 2014 - link
What I don't get is why people say the Windows Phone stores cloud back compiles to native every time someone downloads an app. Can't they just keep the native code for each device, and compile it to the full amount of optimization just once? Yes they have more devices than Apple, but they also tightly control which SoCs WP uses.skiboysteve - Wednesday, July 2, 2014 - link
Yeah C# is very similar to Java in this regard. It even has a large object heap just like ART does.However, as pointed out in other places... Its not JITted on the device. Its done in the cloud.
Flunk - Wednesday, July 2, 2014 - link
.NET on Windows (desktop_ has supported AOT compilation since at least version 2.0, possibly before (I don't recall). It also caches the JIT images so It's not 100% comparable to the way Dalvik works. Heck, even the user can generate native images for .NET programs by running the ngen.exe tool on .NET code.Most commercial .NET programs either use AOT compilation or compile the entire program on first run.
usama_ah - Tuesday, July 1, 2014 - link
The first time I booted the Nexus 7 2013 on the L preview I actually killed the boot process. It was taking so long, it had to be frozen. I must've screwed up the flashing, I thought. So I flashed again, and this time was more patient. The initial boot took quite a while, but turns out it was probably related to these underlying changes in Android.The Nexus 7 2013 never felt slow, but I didn't know it could run this fast. The browser scrolls to an almost iOS like smoothness. I say almost because there are (very) rare hiccups in the FPS but I actually believe those maybe 2/2 to the "preview" nature of this OS.
I am very happy and excited for where Android will go in the next year. I think Android can finally bring it to iOS and Windows Phone when it comes to interface/GUI smoothness.
jeffkibuule - Tuesday, July 1, 2014 - link
I had no doubt Google would eventually get there in stock Android, only question is whether OEMs will muck it all up during their "optimization" process before they ship out their phones.darwinosx - Thursday, July 3, 2014 - link
Google isn't there. Not true 64 bit and using any JIT still doesn't best compiled code which has also gotten a lot more efficient.Alexey291 - Sunday, July 6, 2014 - link
erm you actually don't know what you're talking about do you :)Dalvik is JIT. Dalvik is the OLD runtime.
ART is AOT. ART is the NEW runtime. That's precisely the precompiled code you were talking about.
And the 64bit is about as "true" as the said 64bit in ios.
/sigh