4 ms·

Meanwhile, iOS has used strictly AOT compilation from the beginning for native applications. And doesn't iOS have a reputation for buttery smooth UIs? Perhaps t

Meanwhile, iOS has used strictly AOT compilation from the beginning for native applications. And doesn't iOS have a reputation for buttery smooth UIs? Perhaps the original AOT compilation approach of ART wouldn't be so bad if it didn't have to be done on the user's device, taking up the user's time while installing apps or upgrading the OS.

flat6turbo 10y ago
ios used to be buttery smooth, until they decided to put probably 10,000 instructions behind every button press event.
Twirrim 10y ago
iOS's advantage in this is that the hardware range is small. It's feasible to do full AOT away from the end user's device. With Android there are hundreds or thousands of combinations of various bits of hardware and drivers, with various levels of compatibility. Device manufacturers have a terrific advantage in being able to produce hardware that is more specialised for the purpose, but there are trade-offs. Compiling all possible variations AOT away from the end device is going to be difficult.
- mwcampbell 10y ago
  Not really. Practically all Android devices support ARMv7 binaries. They have to, in order to work with applications that use the NDK. If what you say about Android were true, then AOT compilation for Windows on x86 wouldn't be feasible either.
  - tachydyne 10y ago
    This comment reminds me, there are actually a bunch of Android tablets that shipped with Intel Atom x86 processors. Intel worked some magic with libhoudini that allowed them to run ARM binaries surprisingly fast. If you're an app maker who actually cares about those devices (like my employer) then you end up building all your native code for x86 too. I recall the ARM binaries running at more than 50% of the native x86 ones, running optimized threaded and vectorized image processing code. I wish Intel would talk more about that library. I'd love to know what techniques it used.
- mike_hearn 10y ago
  The Play Store could AOT compile things on the server side. I don't know why it doesn't, it seems like such an obvious win.
  - esprehn 10y ago
    The binaries produced from the AOT process are too large to download over the network for typical users and data plans.
    - pjmlp 10y ago
      Yet Apple and Microsoft managed to do it.
      - mike_hearn 10y ago
        In fairness, they managed to do it only for the highest of high end users. Apple institutionally doesn't care about anyone in places like China, India or Africa where data is expensive. That's why Android completely dominates the global smartphone market share. I guess nothing would stop the Play Store from AOT compiling binaries just for users with fast connections though.
        pjmlp 10y ago
        Windows Phones were widely available in India, before everything kind of felt apart, though.
      - kllrnohj 10y ago
        Microsoft ships .NET bytecode (so basically the same thing Android does) and Apple doesn't care about the low end.
        pjmlp 10y ago
        No it doesn't. WP 8 and 8.1 use MDIL, Machine Dependent Intermediate Language, basically machine code with jump targets kept as symbolic links, replaced at installation time. WP 10 uses .NET Native. I can gladly point out the respective Microsoft documentation, BUILD and Channel 9 presentations.
mike_hearn 10y ago
Smooth but for many years, smooth only until you tried to switch app. iPhones did not have enough RAM to really do more than one thing at once, so multi-tasking came years late and the legacy of that is still present in the very weak, hacked together way in which apps collaborate on that platform. Perhaps this lack of emphasis on multi-tasking and linking apps together is partly due to the decision to AOT compile everything, creating additional RAM pressure. Also, Android was able to scale down to cheap devices, and scale up to very high end devices. Apple basically ceded the entire budget smartphone space to Android, they didn't even try, and budget phones (especially in developing countries) are often characterised by being RAM constrained. So it's a complex topic.
- mwcampbell 10y ago
  Interesting. I was under the impression that Android had more problems with RAM pressure than iOS, because Android uses tracing GC rather than reference counting. I observed that as late as the iPhone 6, the flagship iOS device had only 1 GB of RAM, whereas contemporaneous flagship Android devices had 2 or 3 GB. I guess I succumbed to the tendency to assume that Apple can do no wrong, leading to the assumption that Apple shipped with less RAM because they didn't need it, not because they were just being cheap.
  - pjmlp 10y ago
    Google did lots of work to fit Android on 512MB devices, also modern Android does use a parallel concurrent GC with just one pause. They also made the JNI stricter, in order to allow compactation on future versions. Windows Phone .NET runtime also uses tracing GC, although the underlying UWP APIs are COM based.
  - mike_hearn 10y ago
    GC technically speaking can reduce the amount of RAM you need, as it can compact the heap whereas a native malloc can't. In practice this effect is hard to measure as the sorts of languages that use compacting GCs tend to be rather pointer and allocation happy, so any gain from compaction gets outweighed by other factors. The specs of the various devices have changed over time. Android scales better: you can give it very little RAM, or a lot, and it'll make best use of it by e.g. keeping more background apps loaded at once. iOS was at least historically much less flexible about this: boosting RAM was not worth as much as in the Android space because app devs would still target older devices for quite a while and so the additional RAM would go unused, and the OS wasn't capable of using the spare for much due to the lack of multi-tasking. Eventually Apple implemented Android-style task switching, so I don't know if that's still true. I haven't done any mobile dev for years. But I also think at some point Apple realised nobody who buys an iPhone actually cares about whether they're getting value for money or what the specs are, so they just stopped competing on that area. I mean they have never reduced the price of the iPhone once, right? Despite the huge fall in underlying component prices over the years. They could ship a device with 128mb of RAM and if it did the same thing as the iPhone 4 people would still buy it, simply because they see themselves as iPhone users and not "smartphone users.
pjmlp 10y ago
Yet, now bitcode is a thing on iDevices, to the point LLVM guys started to discuss a possible portable version without the low level hardware bitcodes. The difference from Apple and Microsoft's bytecode solutions versus Google, is that the AOT compilation of bytecode takes place at the store, instead of the device.
kllrnohj 10y ago
iOS's smoothness doesn't come from being AOT. If it did you'd have seen a huge difference in responsiveness in Android between interpreted, JIT & AOT, but you don't. Raw code perf does improve from interpreted -> JIT -> AOT, but the rendering is part of the platform not the app and that's been C++ since the beginning. dalvik's GC was a big problem for smooth UIs, though.

flat6turbo 10y ago

ios used to be buttery smooth, until they decided to put probably 10,000 instructions behind every button press event.

Twirrim 10y ago

iOS's advantage in this is that the hardware range is small. It's feasible to do full AOT away from the end user's device. With Android there are hundreds or thousands of combinations of various bits of hardware and drivers, with various levels of compatibility. Device manufacturers have a terrific advantage in being able to produce hardware that is more specialised for the purpose, but there are trade-offs. Compiling all possible variations AOT away from the end device is going to be difficult.

mwcampbell 10y ago
Not really. Practically all Android devices support ARMv7 binaries. They have to, in order to work with applications that use the NDK. If what you say about Android were true, then AOT compilation for Windows on x86 wouldn't be feasible either.
- tachydyne 10y ago
  This comment reminds me, there are actually a bunch of Android tablets that shipped with Intel Atom x86 processors. Intel worked some magic with libhoudini that allowed them to run ARM binaries surprisingly fast. If you're an app maker who actually cares about those devices (like my employer) then you end up building all your native code for x86 too. I recall the ARM binaries running at more than 50% of the native x86 ones, running optimized threaded and vectorized image processing code. I wish Intel would talk more about that library. I'd love to know what techniques it used.
mike_hearn 10y ago
The Play Store could AOT compile things on the server side. I don't know why it doesn't, it seems like such an obvious win.
- esprehn 10y ago
  The binaries produced from the AOT process are too large to download over the network for typical users and data plans.
  - pjmlp 10y ago
    Yet Apple and Microsoft managed to do it.
    - mike_hearn 10y ago
      In fairness, they managed to do it only for the highest of high end users. Apple institutionally doesn't care about anyone in places like China, India or Africa where data is expensive. That's why Android completely dominates the global smartphone market share. I guess nothing would stop the Play Store from AOT compiling binaries just for users with fast connections though.
      - pjmlp 10y ago
        Windows Phones were widely available in India, before everything kind of felt apart, though.
    - kllrnohj 10y ago
      Microsoft ships .NET bytecode (so basically the same thing Android does) and Apple doesn't care about the low end.
      - pjmlp 10y ago
        No it doesn't. WP 8 and 8.1 use MDIL, Machine Dependent Intermediate Language, basically machine code with jump targets kept as symbolic links, replaced at installation time. WP 10 uses .NET Native. I can gladly point out the respective Microsoft documentation, BUILD and Channel 9 presentations.

mike_hearn 10y ago

Smooth but for many years, smooth only until you tried to switch app. iPhones did not have enough RAM to really do more than one thing at once, so multi-tasking came years late and the legacy of that is still present in the very weak, hacked together way in which apps collaborate on that platform. Perhaps this lack of emphasis on multi-tasking and linking apps together is partly due to the decision to AOT compile everything, creating additional RAM pressure. Also, Android was able to scale down to cheap devices, and scale up to very high end devices. Apple basically ceded the entire budget smartphone space to Android, they didn't even try, and budget phones (especially in developing countries) are often characterised by being RAM constrained. So it's a complex topic.

mwcampbell 10y ago
Interesting. I was under the impression that Android had more problems with RAM pressure than iOS, because Android uses tracing GC rather than reference counting. I observed that as late as the iPhone 6, the flagship iOS device had only 1 GB of RAM, whereas contemporaneous flagship Android devices had 2 or 3 GB. I guess I succumbed to the tendency to assume that Apple can do no wrong, leading to the assumption that Apple shipped with less RAM because they didn't need it, not because they were just being cheap.
- pjmlp 10y ago
  Google did lots of work to fit Android on 512MB devices, also modern Android does use a parallel concurrent GC with just one pause. They also made the JNI stricter, in order to allow compactation on future versions. Windows Phone .NET runtime also uses tracing GC, although the underlying UWP APIs are COM based.
- mike_hearn 10y ago
  GC technically speaking can reduce the amount of RAM you need, as it can compact the heap whereas a native malloc can't. In practice this effect is hard to measure as the sorts of languages that use compacting GCs tend to be rather pointer and allocation happy, so any gain from compaction gets outweighed by other factors. The specs of the various devices have changed over time. Android scales better: you can give it very little RAM, or a lot, and it'll make best use of it by e.g. keeping more background apps loaded at once. iOS was at least historically much less flexible about this: boosting RAM was not worth as much as in the Android space because app devs would still target older devices for quite a while and so the additional RAM would go unused, and the OS wasn't capable of using the spare for much due to the lack of multi-tasking. Eventually Apple implemented Android-style task switching, so I don't know if that's still true. I haven't done any mobile dev for years. But I also think at some point Apple realised nobody who buys an iPhone actually cares about whether they're getting value for money or what the specs are, so they just stopped competing on that area. I mean they have never reduced the price of the iPhone once, right? Despite the huge fall in underlying component prices over the years. They could ship a device with 128mb of RAM and if it did the same thing as the iPhone 4 people would still buy it, simply because they see themselves as iPhone users and not "smartphone users.

pjmlp 10y ago

Yet, now bitcode is a thing on iDevices, to the point LLVM guys started to discuss a possible portable version without the low level hardware bitcodes. The difference from Apple and Microsoft's bytecode solutions versus Google, is that the AOT compilation of bytecode takes place at the store, instead of the device.

kllrnohj 10y ago

iOS's smoothness doesn't come from being AOT. If it did you'd have seen a huge difference in responsiveness in Android between interpreted, JIT & AOT, but you don't. Raw code perf does improve from interpreted -> JIT -> AOT, but the rendering is part of the platform not the app and that's been C++ since the beginning. dalvik's GC was a big problem for smooth UIs, though.