Ever since we first saw ART appear alongside the release of Android 4.4 KitKat, we all knew that it would eventually replace the aging and relatively inefficient Dalvik runtime compiler. Well folks, the time is now upon us, as commits made late last night to the AOSP master branch show Dalvik getting the axe and ART being set as the default.
Should deliver some decent performance improvements. I tried switching to ART months ago but ran into problems with some applications not working properly. Has the situation improved? Are any of you using ART?
I did have some marginal issues with some apps (mx player or bgee for example) which were quickly fixed by the app developers. Pretty much been running on ART since I bought a Nexus5 a year ago. Never looked back.
I’ve been using ART on my Moto G ever since I got it. Admittedly I’m not the type that installs a thousand apps on his phone, but I’ve not encountered any issues.
I’ve suspected this for 2 or 3 weeks now.. Many apps have been getting updated for ART in the last 2 weeks (at first I thought it was just coincidental, but then I realized Google’s event is just around the corner).
This will actually be really interesting when it happens, because, in the past, Android has been operating with a performance hit caused by the execution method (which has been a BIG advantage for Apple). However, now that ART is becoming readily available, Apple’s last real advantage over Android will finally no longer exist.
Hopefully, this technology also allows for increased battery life too.
Nice theory, but ART doesn’t mean it’s the same as native. As evidenced in this thread where most people don’t even notice a difference in speed
Most of the reasons people perceive Android as slower than iOS have nothing to with raw processing speed.
Edited 2014-06-20 01:06 UTC
I can’t say that I’ve noticed any performance difference at all with ART.
I’ve also been running ART for months now on my Nexus 4. I haven’t noticed too much of a performance boost with ART, but I have noticed better battery life. Still not anywhere near what I wish it would be but I can live with it now (I also got a Qi charger and that helps a lot).
They should also improve the emulator speed.
The Windows accelerator module is only available for Intel, no AMD version which is only available for Linux :/
Kochise
It is not nice to see how Google and Intel are so FOSS supporters that only bother to support HAXM on Windows?
Got to love corporations.
The Xposed module is a fantastic system. Only hope that its developer can transition to ART soon. A lot of folks use it.
I hope so too as i use xposed framework a lot, this is the only thing to hold me back from art….
Someone committed a better version of ART called Fast ART. For some reason, they didn’t add the F to the acronym.
I’ve been using ART on my N7 2013 LTE for the last 3 or 4 months and haven’t noticed any problems that I can attribute to ART.
I switched to ART on my Nexus 5 right after upgrading to 4.4.3. So far I have had no problems at all.
On the other hand I do not notice much of a performance improvement either, but I mostly use the phone for reading mail browse the web, calendaring, checking documents on google drive and similar office oriented tasks. And for that even my old Galaxy Nexus with Android 4.3 was quite fast enought.
Many of my tasks also depend on intenet connection, so perhaps its not surprising that I don’t see much of an improvement. Heavy gamers may notice i t more.
What I do notice howerver is sligthly better battery life.
Just a reminder: ART will eliminate the performance penalty of dalvik, but will make app installation times longer, because all the dalvik code of the app will have to be converted to native.
Which brings the question: What is the point of Dalvik anyway? Most Android apps have portions of native code where performance is needed, or OpenGL (or NEON) need to be accessed. So, the supposed advantage of apps running on multiple architectures is moot. But the disadvantage of the occasional perfomance penalty (when running uncached code) and the need for a dalvik cache remains.
Part dalvik, part native apps (aka most of them), is clearly a case of worst of both worlds.
The one thing iOS did right is go all native and get rid of those useless emulators.
Edited 2014-06-19 15:03 UTC
I’m presuming (and this is a fairly big presumption) that there is a fallback if the native part of the app can’t find an ArmV7 CPU, would be up to the dev to code this in though.
For something like OpenGL the performance hit would be huge but would still preserve compatibility across platforms.
Still, your point is a good one.
Uhm, ios is also switching to Swift. Because objective C has some real run time penalties that slow it down more than it needs to be slowed down. Late binding, swizzling, automatic garbage collection and exceptions all slow it down.
Swift compiles to machine code on iOS. Most languages compile to machine code on iOS – Java, C#, even Actionscript 3.0!
Automatic garbage collection does not slow things down. You need to collect garbage, which you can do:
1. Manually. Programmers can’t be trusted to do that, very hard in case of cyclic references.
2. Reference counting: big overhead.
3. Automatic, best method, but requires a good gc, ideally something that has a multi-generation heap, can compact the heap, and can run concurrently without pauses.
Well, it sounds like you are talking about garbage collection in the abstract.
In Objective C it was so bad, they never even made it available in ios, and are removing it from a future version.
http://en.wikipedia.org/wiki/Objective-C#Garbage_collection
It never stops to amaze me how Apple’s inability to make GC work in Objective-C keeps getting used as example why GC is bad.
Apple’s GC implementation was half-baked with lots of corner cases, requiring frameworks to be explicitly compiled with GC support to work well together. When not, lots of strange bugs used to pop up.
One just needs to browse the old developer pages to see how much corner cases which required developer’s attention were required. The developer forums had quite a few ongoing discussions about hard to track down crashes.
Objective-C ARC only works better than GC, because it only applies to classes that follow Cocoa retain/release patterns, so in practice the compiler is writing what the developers were already doing by hand.
But better sell failure as the new solution is better.
I am against auto garbage collection, but I totally understand that Apple sucked it up big time in their implementation. I don’t think I stated otherwise.
And yet Modern C++ (shared_ptr+weak_ptr), Modern Objective C (ARC) and Swift (also ARC) are doing that just fine.
Depends. In most situations the overhead does not matter. On the other hand the overhead is constant, predictable and works for resource management as well.
GC vs ARC have each their pros and cons. The big problem with the GC approach is that while memory is usually plentyful, other resources are not and the GC is incompatible with one of the easiest resource management tools: destructors. For example, for every place a C++ project uses scope and destructors, most GC based languages requires some kind of try/finally clause to ensure you do not get memory gathering or resource exhaustion issues.
And quite frankely most developers have just as hard a time remembering to type try/finally as they had remembering to type delete in the infamous 1990’s C and C++ days.
[/q]
Modern C++ RC is slower than incremental generational GC, specially if pointers are shared across threads.
Modern Objective C can only be used with classes that follow Cocoa retain/release patterns. Every thing else requires manual memory management.
Swift ARC still leaves lot of room to improvement according to the benchmarks being made available.
You are missing the point. I am not questioning that pure GC benchmarked against reference counting is faster always (even with an awful stop-the-world GC runtime). But ARC has the advantage that resource management becomes a lot easier and for most objects we actually only have a relatively low count where the speed of ARC does not matter.
Add to that an ARC system also runs at a more predictable speed. This part is comparable to the Linux scheduler discussions where on a server you want the overall fastest completion time, while you on a desktop want the earliest possible UI response even if that means the thing finishes a little bit slower.
Personally I wish more language designers would realize that we need both at the same time, so that resource oriented things can be ARC while pure memory structures can be GC.
I beg to differ.
Most ARC systems tend to be more hard to use as they place on the shoulders of the developers the responsibility to specify pointer types.
Also you can have the same stop-the-world effect when the reference count reaches zero and a graph needs to be deleted.
Not to mention that unless cleaver RC algorithms are used, each read is transformed into a write, which just kills performance at the cache level with shared pointers.
Most GC programming languages do offer ways to deterministic call clean-up functions/methods if required to do so.
They also have tooling that allows the developers to monitor and control the GC, so that the code can be fine-tuned.
Languages like Modula-3 and D go in the direction that you are speaking, though.
You get GC by default, with generic library data types for reference counted data structures.
Well, you’re right of course, but at the same time, destructors are not the easiest way to do resource management in C++. They’re the only way. More specifically, the only code that’s guaranteed to be executed in C++ is the destructors of stack allocated objects, therefore the only place to put resource deallocation is destructors. I’m not saying it’s wrong, mind, just… let’s not confuse virtue with necessity.
Dalvik is the Java virtual machine with JIT. It’s a fine strategy for running intermediate machine code (DEX in Android’s case). AOT is just a different strategy. It compiles ahead of time, instead of generating machine code at runtime. Each has it’s advantages and disadvantages, and AOT isn’t always faster, despite popular belief. ART is faster in the specific case of ART vs Dalvik, because Dalvik was never particularly fast, especially compared with other JIT based VMs such as .NET’s CLR, Sun’s JVM, or Mono. Even Chrome’s V8 (JIT) is faster than Dalvik. I’ll bet some of these JIT Based VMs will remain faster than ART for a while yet, though Google will certainly keep working on it.
AOT is always faster if used together with PGO, unless we are talking about dynamic languages.
JIT compilers need to compromise speed vs code quality.
It’s not, though. AOT needs to make assumptions about the specific processor used (and even, nowadays, GPU). JIT, on the other hand, suffers the penalty of compiling every time the programs starts, which implies not doing time-consuming optimisations.
Considering the variety of CPUs and vector extensions available, especially on phones, delaying compiling (as in, compiling to machine code) until the runtime environment is known offers the best performance – except in the case of download then run immediately.
The usual JIT marketing material.
Yes, AOT compilation cannot target all processors in the world that the application might run on.
However, AOT compilation enjoys more computing power as there isn’t any user interacting with the application. This allows the usage of strong optimization algorithms that aren’t possible within the constraints of JIT usage scenarios.
Add to it PGO and the result is AOT code beating JIT generated code in performance benchmarks.
Yes, there is this idea JIT compilers can be optimized to newer processors without updating code. However they cannot use strong optimization algorithms, which leads to the usual mix of parallel execution with multiple JIT layers.
You also don’t control which JIT compiler is available on the target computer, so code optimizations where you rely on the JIT compiler behaviour are hit-and-miss.
Google is only following what Apple and Microsoft have been doing in the last years by going back to AOT compilation.
It’s like I said:
. And on the other hand “traditional” AOT (when the shipped product is an native executable) cannot hope to be optimised for the final execution environment, not these days, and that’s that.
The obvious middle ground is to ship some form of bytecode and compile that on the final device, but just once. Either during installation, or possibly during the first execution (and store the result). Because it’s only once, it’s acceptable to spend the time to do all the complex optimisations, so you sort of get the best of both worlds (except for dynamically loaded code). You can even gather profiling data for the actual user and recompile at some point later. In principle.
And that’s what ART is doing. AFAIK.
There’s no tecnical reasons why ART should be faster than Dalvik, other than more optimization work have been done by Google on ART rather than Dalvik. By its technology, ART should be faster during the first startup and the first execution of an application (the code compiled by Dalvik is then cached too). However the better startup time usually give to users the perception of more speed.
All this obviously applies only on Java code, applications compiled with NDK will not be affected.
The main drawback is that all the Java applications will occupy roughly twice the space: the bytecode and the compiled code.
Another possible drawback is that the code will not be profiled during runtime, losing the possibility to be further optimized: this is the reason why HotSpot is faster than gcj or jet on longer executions that compensate the time spent into compilation and optimization.
AOT vs JIT:
http://www.ibm.com/developerworks/java/library/j-rtj2/index.html#N1…
Early ART benchmarks, including battery usage:
http://www.androidpolice.com/2013/11/12/meet-art-part-2-benchmarks-…
http://www.androidpolice.com/2014/01/22/meet-art-part-3-battery-lif…
Disadvantages with native or almost native architectures, like Apple, Jolla, Tizen, etc., surely will not be eliminated at all. These were obviously clear from the beginning of Android development: they preferred to have better sandboxes and CPU neutrality.
In fact there are reasons why Dalvik is slower than ART. It is presented even in their initial presentation of Android’s JIT Google IO talk: Dalvik’s JIT is a tracing JIT. In human language speak is basically that Dalvik can optimize code as long as is it a straight line.
ART is a full compiler and it has a “bigger window of opportunity” to optimize the code as it can check all the branches of the code flow.
Cellphones with interactivity is the bane of western society. No social interactivity in the real world i happening any more. Go to any industry and look at the activities of the lunch room. There is no need to automation any longer, as the are all robots and Zombies.
The only way to win is not to play. Opt out!
OK, I don’t know if your comment is serious or sarcastic but I do find sad that wherever I go now I see tables filled with young people rubbing their fingers on phones instead of talking to each other most of their time.
Anyway, we can argue that phones are freeing us from talk to people just because they are close and giving us the liberty to talk to people that have something we really like, no matter where they may be.
It also does not help that we, somehow, feel easier to say what we really think or just plain ignore a direct message altogether, when the one on the other side is not on front of us
Yeah, I remember when the same thing was said about television….
I did this in the developer options section of the phone all i have noticed is that after the phone taking a long time to recompile every application it is now used up more than a gig of additional internal storage. i needed that space so i will have to return to dalvik.