

Ask HN: Are there reasons beyond efficiency for ART vs. Dalvik on Android - ximeng

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
None 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
Thanks, 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_resul...](http://www.theregister.co.uk/Print/2014/05/02/arm_test_results_attack_intel/)
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-...](http://www.extremetech.com/computing/130552-intel-
dismisses-x86-tax-sees-no-future-for-arm-or-any-of-its-competitors) .

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

