macOS Did no one watch the State of the Union session

[lloyddean]

Sorry to wake you but ...

(... and this will probably be moved but ...)

Apple has all but annouced the target architecture of either an architecture transition or (more likely) the addition of another architecture to it's iOS and or Mac product lines within the next couple of years and it's dead quiet in here.

Is anybody paying attention.

Go back to sleep.

 

[Senor Cuete]

Please tell me that you're not THIS lloydean inOregon:

http://www.spiritofmaat.com/archive/oct4/lloydine.htm

 

[lloyddean]

Not even close. A whole state away in fact!

 

[Gwendolini]

When did this happen in the SotU?

 

[iSee]

I watched only part of it so far... are you referring to Bitcode?

It seemed to me that it allows them to continue to introduce new processor architectures with zero impact on almost all developers.

I say "continue" because they've been adding new processor architectures and extending existing ones all the time... consider each A* chip and the chips they get from Apple that they use in their Macs. This would allow them to do this more frequently and more easily, but it didn't strike me as anything new, really. I mean, you can certainly see how this could lay the ground work for, e.g., a Mac that uses an Apple A11 SOC (or whatever)

...

For those that haven't heard, Bitcode is like a compiled binary but where your source code is compiled to LLVM Intermediate Representation rather than to the machine language of a specific processor architecture. Apple is going to start accepting (and even requiring) apps that are compiled to bitcode.

It sounded like the app store would take care of running the Bitcode through the LLVM optimizer to produce processor architecture-specific machine code so that the app users download will contain a binary specific to the device. (Not sure what this means for synching apps to your device via iTunes -- that would need to change as well to support this.)

This would allow Apple to introduce new processor architectures with no impact on existing apps: Since Apple has the LLVM IR for the app, they can generate a binary for a new processor without involving the app developer.

This would also allow existing apps to take advantage of new instructions added to for a chip revision (without the developer needing to re-release).

Note that the process of compiling source to LLVM IR and then LLVM IR to processor-specific binary is proven. This is what Xcode has been doing for a while now when you compile your app. The new part is that you sumbit the bitcode to Apple rather than multiple architecture-specific binaries.

 

[chown33]

I haven't read anything saying that Bitcode will apply to Macs. Maybe I missed it.

Here's an article with the longest discussion I've read so far:
http://arstechnica.com/apple/2015/0...ajor-boon-for-8gb-and-16gb-iphones-and-ipads/

It doesn't mention OS X or Macs as targets, only iOS and WatchOS.

 

[lloyddean]

Glad to see I'm not the only one that sees the implications.

Yes it's announced only for iOS at this point but one can see the possibilities for other Apple platforms at some future time. Including the rumored Arm based Mac Platform. Not saying it's going to happen but that Apple has layer the foundation should they choose other architectural paths going forward. And requiring no effort for developer beyond the use of Swift 2.x and the tools supplied in Xcode.

Of course for this to work for Mac OS application would require distribution thru the Apple App Store or perhaps not given Apples Enterprise distribution method for iOS.

 

[Sydde]

Of course for this to work for Mac OS application would require distribution thru the Apple App Store or perhaps not given Apples Enterprise distribution method for iOS.

How bulky is the llvm code generator? Could that be an OS library, so that the final code generation occurs right at home? Seems like they could fairly easily fold that right into the download process so that there would be no observable build delay after the download finishes, take some load off the server, and the final build would be ideally optimized for the specific machine. Developers would just have to supply an IR with source clean-up and basic performance optimization.

 

[chown33]

How bulky is the llvm code generator? Could that be an OS library, so that the final code generation occurs right at home? Seems like they could fairly easily fold that right into the download process so that there would be no observable build delay after the download finishes, take some load off the server, and the final build would be ideally optimized for the specific machine. Developers would just have to supply an IR with source clean-up and basic performance optimization.

I don't think there's that much extra load on the server.

There are a finite and fairly small number of target devices. As a simplified example, consider 3 CPUs and 2 models: that's 6 distinct targets. Even if there are 20 or 30 targets, it's not a big deal. The code (and trimmed resource set) for a given target only needs to be generated once. It can be cached on the disk thereafter, and the server doesn't need to regenerate it until the files get pushed out of cache.

A pre-generated cached target only consumes disk space, and the disks can be pretty big. Yes, it's more disk space than if there weren't multiple targets, but disk space is generally less expensive than server processing time.

Obviously, Apple can't cache every target for every app, but it's quite feasible for the common targets and the popular apps. I could see this simple strategy covering 99% or more of total App Store downloads, depending on how much disk space Apple wants to use.

 

[bumblebritches5]

Glad to see I'm not the only one that sees the implications.

Yes it's announced only for iOS at this point but one can see the possibilities for other Apple platforms at some future time. Including the rumored Arm based Mac Platform. Not saying it's going to happen but that Apple has layer the foundation should they choose other architectural paths going forward. And requiring no effort for developer beyond the use of Swift 2.x and the tools supplied in Xcode.

Of course for this to work for Mac OS application would require distribution thru the Apple App Store or perhaps not given Apples Enterprise distribution method for iOS.

It doesn't require Swift, it would work just as well in C or C++. this is a compiler feature, not a language feature.

 

[firewood]

Bitcode might also allow for easier or more thorough screening for inappropriate API usage, and better custom codesigning, or encryption, or watermarking of each compiled binary. Final compilation on the device also allows Apple to better hide their custom changes to the CPU instruction set.

 

[Sydde]

Hell, you might even be able to put together a LLVM IR from Haskell or Fortran, if the language provided proper API support.