4 ms·
Ask HN: Are there reasons beyond efficiency for ART vs. Dalvik on Android
Wondering if ART is designed to make it easier for Android to run on Intel architectures, or if there are legal reasons for the shift to ART. Understood that work on ART has been ongoing for a while and the previous principle architect of Dalvik left Google a while back.
- UnoriginalGuy 12y agoNone that I've ever read (but I also don't work for Google, so external docs only). ART improves app load times, runtime performance, and reduces battery usage. That effect is somewhat amplified by AOT-ing services/APIs that apps rely on, so instead of just seeing the improvements within a single APK, you might see a single app-load improved by three or more APKs being AOT-ed. Not that dissimilar from Ngen in the .Net/CLI world. Intel won't benefit more (or less) than other architectures. They're both doing the same work, just doing it at a different point in time. So unless Intel or someone has developed a really awesome static analysis tool which just happens to be too slow to shove into the JIT pipeline, it shouldn't make a huge amount of difference (and I've read nothing about an Intel specific dex2oat). As to legal: Most of Google's issues with Oracle have been resolved. They related to a bunch of Oracle's patents and something about the Java library. ART doesn't really change how anything works, you're still interpreting bytecode into local instructions, you're still using the same libraries, and even the whole workflow hasn't really changed. Just moved around WHEN stuff happens not WHAT happens. So while IANAL, I don't know if how ART would be a legal maneuver. If anything it exposes them to additional patent liability as the process is more complicated and third parties could claim they "own" part of it.
- ximeng 12y agoThanks, interesting commentary, and your point on Google / Oracle all makes sense. One question regarding the architecture would be whether there is more of a performance improvement on x86 versus ARM for the ART pipeline compared to the pipeline for Dalvik. ARM are saying Intel performance suffers mostly because of native code - http://www.theregister.co.uk/Print/2014/05/02/arm_test_results_attack_intel/ http://www.theregister.co.uk/Print/2014/05/02/arm_test_resul... while not speaking to performance of Dalvik versus ART on the two platforms. Intel are pushing their performance and scale while skipping over the native code question: http://www.extremetech.com/computing/130552-intel-dismisses-x86-tax-sees-no-future-for-arm-or-any-of-its-competitors http://www.extremetech.com/computing/130552-intel-dismisses-... . It sounds from what you say that ART doesn't really change the balance between Intel and ARM in any significant way, so that leaves the question of whether the problems Intel has with translating apps with native code compiled to ARM targets can be overcome by any manufacturing advantages Intel may enjoy.
- on_and_off 12y agoART is considered to be Dalvik 2.0. The main reason is that many of the choices made by Dalvik are no longer relevant in the current technical environment. SOCs have evolved a lot since Android 1.0 . I doubt that ARM vs Intel has a lot of weight from Google's point of view.. it is not really Google's issue. We can also hypothesize that ART more pluggable architecture is here to allow Google to maybe switch languages at some point in the future. There is nothing official in that regard though, quite the contrary (cf the I/O fireside chat where the Android team clearly said that Java is Android's language). So, either they are working on a replacement language in secret or this is just a nice result of the new build system and runtime.