5 ms·

> 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

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

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.