3 ms·

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 pr

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