3 ms·

It is relevant to the user for two reasons: portability and speed. In contrast to iOS, Android in the wild runs on everything from ARM to x86, in many different

It is relevant to the user for two reasons: portability and speed. In contrast to iOS, Android in the wild runs on everything from ARM to x86, in many different generations. Doing the compilation on the device allows the AOT compiler to optimize for the specific CPU that the device uses. Also, it increases compatibility, because what is shipped is platform-independent bytecode, not a binary that may only target one specific architecture.

pjmlp 12y ago
This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. I code mainly in C++ (NDK) and don't have any issues delivering code.
- vetinari 12y ago
  > known as fat binaries or delivering multiple binaries in a package. That's not a solution, that's band aid. Fat binaries or multiple binaries cannot support future architectures or architectures that the original developer doesn't support. Platform independent bytecode can.
  - pjmlp 12y ago
    That is the theory, which I preached for a long time as well. The real life looks a bit different. An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. So gcc and clang can easily outperform Dalvik in < 4.4 generations, given that it was hardly changed since 2.3.
    - danieldk 12y ago
      An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. For one application. And again, your binaries will be very fat if you want to optimize for every possible CPU generation. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. Also, for optimization for a particular CPU it should not matter if ART is not upgraded, as long ART was optimized for the CPU at the time the phone was released. (Of course, you would miss out on newer optimizations in ART.)
      - pjmlp 12y ago
        > Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. That is why I said: -- quote That is the theory, which I preached for a long time as well. The real life looks a bit different. -- quote So one is bound to use the approach that works best, regardless of how it could be.
    - vetinari 12y ago
      It still depends on you, as a developer, to recompile the app for the target cpu. I have a collection of M68K and PPC Mac binaries, that nobody is going to recompile for me. I would take sub optimally running app over not-running-at-all app any day.
      - pjmlp 12y ago
        > I have a collection of M68K and PPC Mac binaries, that nobody is going to recompile for me. Apple did. http://en.wikipedia.org/wiki/Rosetta_%28software%29 http://en.wikipedia.org/wiki/Rosetta_%28software%29
        vetinari 12y ago
        Rosetta is not supported in current systems. Since 10.7., I think. Classic, which provided the ability to run Classic M68K and PPC binaries, had it's last release in 10.4. It wasn't supported in 10.5 and it never run on Intel Macs. Not to say, that both these technologies are limited hacks compared to proper platform-independent bytecode ala Dalvik, ART, Java or CIL.
    - ZeroGravitas 12y ago
      "Whereas Dalvik and ART are stuck to the versions that were burned into the silicon." I don't understand this comment? What hardware is the Dalvik and ART stuff wedded to?
      - pjmlp 12y ago
        The ROM containing the firmware. Except for the top OEMs, most Android devices don't get any updates, so you are stuck with the JIT that was burnt into the firmware.
        danieldk 12y ago
        What do you mean by 'ROM' or 'burnt'? Android is normally on flash storage. Even if a device does not get updates anymore, you could still replace it if the boot loader is unlocked (e.g. Cyanogenmod). Of course, you know this, so I can only assume that you are using such words for dramatic effect ;).
        pjmlp 12y ago
        Which normal users are unlocking their devices? It doesn't matter if it is flash, eprom, rom, whatever. The practical result is that most devices die with the Android version they were bought with.
        vetinari 12y ago
        Normal users do not care about firmware versions or cpu optimizations. An app either runs, or not. Dalvik allows the apps to run, without the user having to know about cpu architecture in their phone or whatever.
        pjmlp 12y ago
        But I as developer care to deliver the best experience in terms of performance from Android 2.3 all the way up Android 5.0.
- danieldk 12y ago
  This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. No, they are not the solution: you cannot provide new optimized versions for generations that did not exist yet when you compiled the binary. Also, providing an optimized version for every ARM, x86, etc. generation will make the binaries very fat. Fat binaries worked for relatively static platforms, such as Macs. For devices which are (still) iterating quickly, it's a suboptimal solution. Sure, it works for delivering code, but it is suboptimal. (Not that I believe that ART is currently optimal, e.g. it should not be necessary to do the compilation of an app on 1 million devices that are identical.)
  - pjmlp 12y ago
    They are only fat at the store, the devices only see the .so they understand. And it isn't that hard to have "APP_ABI := all" in Application.mk. The build just takes a little longer on the CI system.
    - izacus 12y ago
      There's currently more than 100 SoCs out there and several major generations of ARM architectures which show clear benefits of GCC compiler tuning for their platform. Tracking all those devices and architectures is dumb, when the manufacturer/device can provide proper tuning for the device itself.
      - pjmlp 12y ago
        Yes, but my experience tells me that "can" != "he/she will".

pjmlp 12y ago

This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. I code mainly in C++ (NDK) and don't have any issues delivering code.

vetinari 12y ago
> known as fat binaries or delivering multiple binaries in a package. That's not a solution, that's band aid. Fat binaries or multiple binaries cannot support future architectures or architectures that the original developer doesn't support. Platform independent bytecode can.
- pjmlp 12y ago
  That is the theory, which I preached for a long time as well. The real life looks a bit different. An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. So gcc and clang can easily outperform Dalvik in < 4.4 generations, given that it was hardly changed since 2.3.
  - danieldk 12y ago
    An a simple example, I can recompile my application and target any device while using 100% of all CPU features in all Android generations. For one application. And again, your binaries will be very fat if you want to optimize for every possible CPU generation. Whereas Dalvik and ART are stuck to the versions that were burned into the silicon. Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. Also, for optimization for a particular CPU it should not matter if ART is not upgraded, as long ART was optimized for the CPU at the time the phone was released. (Of course, you would miss out on newer optimizations in ART.)
    - pjmlp 12y ago
      > Which is a problem with how Android updates are distributed, not the principle of doing AOT compilation on byte code. I think pretty much everyone agrees that the push of updates to Android devices sucks, compared to iOS or, to some extend, Windows Phone. That is why I said: -- quote That is the theory, which I preached for a long time as well. The real life looks a bit different. -- quote So one is bound to use the approach that works best, regardless of how it could be.
  - vetinari 12y ago
    It still depends on you, as a developer, to recompile the app for the target cpu. I have a collection of M68K and PPC Mac binaries, that nobody is going to recompile for me. I would take sub optimally running app over not-running-at-all app any day.
    - pjmlp 12y ago
      > I have a collection of M68K and PPC Mac binaries, that nobody is going to recompile for me. Apple did. http://en.wikipedia.org/wiki/Rosetta_%28software%29 http://en.wikipedia.org/wiki/Rosetta_%28software%29
      - vetinari 12y ago
        Rosetta is not supported in current systems. Since 10.7., I think. Classic, which provided the ability to run Classic M68K and PPC binaries, had it's last release in 10.4. It wasn't supported in 10.5 and it never run on Intel Macs. Not to say, that both these technologies are limited hacks compared to proper platform-independent bytecode ala Dalvik, ART, Java or CIL.
  - ZeroGravitas 12y ago
    "Whereas Dalvik and ART are stuck to the versions that were burned into the silicon." I don't understand this comment? What hardware is the Dalvik and ART stuff wedded to?
    - pjmlp 12y ago
      The ROM containing the firmware. Except for the top OEMs, most Android devices don't get any updates, so you are stuck with the JIT that was burnt into the firmware.
      - danieldk 12y ago
        What do you mean by 'ROM' or 'burnt'? Android is normally on flash storage. Even if a device does not get updates anymore, you could still replace it if the boot loader is unlocked (e.g. Cyanogenmod). Of course, you know this, so I can only assume that you are using such words for dramatic effect ;).
        pjmlp 12y ago
        Which normal users are unlocking their devices? It doesn't matter if it is flash, eprom, rom, whatever. The practical result is that most devices die with the Android version they were bought with.
        vetinari 12y ago
        Normal users do not care about firmware versions or cpu optimizations. An app either runs, or not. Dalvik allows the apps to run, without the user having to know about cpu architecture in their phone or whatever.
        pjmlp 12y ago
        But I as developer care to deliver the best experience in terms of performance from Android 2.3 all the way up Android 5.0.
danieldk 12y ago
This is a solved problem since the early 80's, known as fat binaries or delivering multiple binaries in a package. No, they are not the solution: you cannot provide new optimized versions for generations that did not exist yet when you compiled the binary. Also, providing an optimized version for every ARM, x86, etc. generation will make the binaries very fat. Fat binaries worked for relatively static platforms, such as Macs. For devices which are (still) iterating quickly, it's a suboptimal solution. Sure, it works for delivering code, but it is suboptimal. (Not that I believe that ART is currently optimal, e.g. it should not be necessary to do the compilation of an app on 1 million devices that are identical.)
- pjmlp 12y ago
  They are only fat at the store, the devices only see the .so they understand. And it isn't that hard to have "APP_ABI := all" in Application.mk. The build just takes a little longer on the CI system.
  - izacus 12y ago
    There's currently more than 100 SoCs out there and several major generations of ARM architectures which show clear benefits of GCC compiler tuning for their platform. Tracking all those devices and architectures is dumb, when the manufacturer/device can provide proper tuning for the device itself.
    - pjmlp 12y ago
      Yes, but my experience tells me that "can" != "he/she will".