5 ms·

As I understand it, the major speed improvements with ART come less from the native compilation than from the improved GC and the ability to do whole-program op

by djur 12y ago

As I understand it, the major speed improvements with ART come less from the native compilation than from the improved GC and the ability to do whole-program optimizations during the AOT compilation step. EDIT: Also, ART takes a different approach to AOT compilation than either iOS and Windows Phone. iOS apps are shipped as compiled binaries from the start, and apparently Windows Phone apps are compiled in the cloud by MS. ART does the native translation step on the device itself, which has only really recently become feasible with the speed and storage capacity of recent Android devices.

higherpurpose 12y ago
I think his main point was that it has caught up with the performance of AOT, not the nitty gritty details behind the process, which is kind of irrelevant to the user.
- danieldk 12y ago
  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.
    - 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
Sure, Dalvik apparently was left to gather dust for a few Android releases. Yes, having the AOT compilation done on the device is an handicap, given how OEMs barely update Android versions. So while Apple and Microsoft approaches mean you can target older devices while enjoying improvements in code generation, with Google's approach you're stuck with whatever the device supports, unless you use the NDK instead.

by djur 12y ago

higherpurpose 12y ago

I think his main point was that it has caught up with the performance of AOT, not the nitty gritty details behind the process, which is kind of irrelevant to the user.

danieldk 12y ago
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.
  - 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

Sure, Dalvik apparently was left to gather dust for a few Android releases. Yes, having the AOT compilation done on the device is an handicap, given how OEMs barely update Android versions. So while Apple and Microsoft approaches mean you can target older devices while enjoying improvements in code generation, with Google's approach you're stuck with whatever the device supports, unless you use the NDK instead.