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
uhuznaa - Thursday, July 3, 2014 - link
Setting scrolling velocity is just a decision of the developers, this is just a parameter. You can make the crappiest hardware scroll like mad. Smoothness (and getting the behaviour close to a believable, consistent physical model of inertness and friction) is really hard work that requires lots of things in the system working right to even allow trying. Android was never good (or consistently good) at that. Google has improved it with every version though.darkich - Thursday, July 3, 2014 - link
"and getting the behaviour close to a believable, consistent physical model of inertness and friction".. And that is exactly where Dolphin trumps everything else, at least for me.
Sure, it's not perfect at all times and on all sides (no browser is, again) but at its best, Dolphin Jetpack is the prime example of the description you gave.. It feels like a real, oily smooth mechanism
jospoortvliet - Thursday, July 3, 2014 - link
Darkich: perhaps this helps:'smooth' is about the dropping of frames or (in)frequently stalling the drawing. It has nothing to do with how quickly you go to the bottom of a page as the browser can simply stop drawing for 1/10th of a second and show the bottom of the page and be fastest to the bottom - yet it would not be smooth at all.
So uhuznaa is right, scrolling speed has nothing to do with how smooth and fluid the UI is. It can be slow but never drop frames or fast but drop frames all the time.
sonicmerlin - Wednesday, July 2, 2014 - link
Lol no. As long as Android continues to run the UI thread on the core thread it will never be as smooth as iOS or WP.uhuznaa - Thursday, July 3, 2014 - link
I don't know if this is the reason but on my old iPhone 4 I can install 5 apps and continue to use an app at the same time without even noticing the installs going on in the background while doing the same on my Nexus 7 only leads to frustration. Same with loading lots of emails or anything else going on in the background. My Nexus always gets seizures and seems to hang for seconds when this happens. iOS seems to prioritize user interaction over everything while in Android user input seems to be treated as just another task to be handled sooner or later.jospoortvliet - Thursday, July 3, 2014 - link
It is possibly part of the reason, but for what you talk about the main reason, I think, is that the Linux kernel is not good at handling I/O while maintaining interactivity. This is actually currently being taken care off but with the linux kernel in android so far behind mainline (linux is at 3.15, android at what, 3.5?) this might take a while to get fixed.Alexey291 - Tuesday, July 8, 2014 - link
throw in the fact that nexus7 (2012) has a terrible nand controller and some really cheap nand chips and you have the result that you have aka stuttering slow trash device.dealcorn - Tuesday, July 1, 2014 - link
Does ART eliminate residual X86 compatibility issues? If so, ARM loses home field advantage.johncuyle - Tuesday, July 1, 2014 - link
Unlikely. Java applications should be the ones that worked anyway on x86. The applications least likely to work would be native applications, which a developer may not compile and distribute for x86. Those are most likely to be games, particularly since Google (bafflingly) discourages use of the NDK.Flunk - Wednesday, July 2, 2014 - link
Why do you find Google discouraging the use of the NDK baffling? The whole reason is the subject of your conversation. Poor compatibility with multiple ISAs.