3 ms·

Apple's recent decision to promote LLVM bitcode as a canonical binary form for apps ("promote" meaning mandatory on the watch) makes me suspicious they're plann

Apple's recent decision to promote LLVM bitcode as a canonical binary form for apps ("promote" meaning mandatory on the watch) makes me suspicious they're planning something similar in their future A-series or S-series chips. The paired relationship between the phone and watch could probably benefit from either side being able to do a little computation and coordination without having to spin up the big cores. There, of course, I'd expect Apple to make it developers' problem to designate which thread(s) could operate in a limited environment.

valarauca1 11y ago
>Apple's recent decision to promote LLVM bitcode as a canonical binary form for apps ("promote" meaning mandatory on the watch) makes me suspicious they're planning something similar in their future A-series or S-series chips. This makes a lot of sense. LLVM byte code is pretty damn portable. It just makes a lot more sense since you can maintain PPC/x64/ARMv8 support of a binary file. Yet have native performance in all environments. What I'd consider more likely is on install you compile to native for both High Power/Low Power chips. It might get funky from an OS standpoint but theoretically you could dyanmically switch between binaries if they were compiled to do that. Its really just dynamic dispatch in Kernel Space.
pjmlp 11y ago
> There, of course, I'd expect Apple to make it developers' problem to designate which thread(s) could operate in a limited environment. Less so when using task queues, I guess.
- twoodfin 11y ago
  Sure, but I'd expect that Apple would provide some API for you to designate certain tasks as intended to be run in the "Deep Background". With the understanding that such tasks are on a very short leash power and capability-wise, and may be arbitrarily cancelled—like iOS's forcible app killing, but at a smaller grain. (Does GCD have a facility for the dispatcher to unilaterally do this already?)

valarauca1 11y ago

>Apple's recent decision to promote LLVM bitcode as a canonical binary form for apps ("promote" meaning mandatory on the watch) makes me suspicious they're planning something similar in their future A-series or S-series chips. This makes a lot of sense. LLVM byte code is pretty damn portable. It just makes a lot more sense since you can maintain PPC/x64/ARMv8 support of a binary file. Yet have native performance in all environments. What I'd consider more likely is on install you compile to native for both High Power/Low Power chips. It might get funky from an OS standpoint but theoretically you could dyanmically switch between binaries if they were compiled to do that. Its really just dynamic dispatch in Kernel Space.

pjmlp 11y ago

> There, of course, I'd expect Apple to make it developers' problem to designate which thread(s) could operate in a limited environment. Less so when using task queues, I guess.

twoodfin 11y ago
Sure, but I'd expect that Apple would provide some API for you to designate certain tasks as intended to be run in the "Deep Background". With the understanding that such tasks are on a very short leash power and capability-wise, and may be arbitrarily cancelled—like iOS's forcible app killing, but at a smaller grain. (Does GCD have a facility for the dispatcher to unilaterally do this already?)