Hacker News Reader

Comment by exelius | Hacker News Reader

You mean just like Java? The performance overhead of Java versus native code is pretty negligible at this point, and Swift is pretty similar to Java 8. I suspect if Apple wanted to go the intermediate compilation route, they would have just used Java.

I suspect Bitcode is more about helping developers ship a single binary that works across 7 or 8 devices with slightly different ISAs. App thinning is a big push for Apple right now because app sizes are getting out of control with the number of variants that developers are required to compile to. Developers compile to Bitcode, then upload to Apple, who then compiles multiple versions of the machine code, using the App Store to download the correct bundle for the device.

View on HN

Every single binary every emitted by LLVM has been Bitcode during the compilation process. The only new element here is that Apple's asking for this intermediate product in order to be on the App Store.

Yep, and what I'm saying is that Bitcode doesn't help portability; only in producing device-optimized binaries for variants of the same ISA. The end goal here is reducing app size, not making it easier to port things to a new ISA. A new ISA wouldn't be impossible -- Apple is one of the few companies to successfully navigate this transition -- but IMO Apple would be better served on the Mac side by lower-power x86 parts (which are finally available) than higher-performing ARM CPUs.

In my industry, app data size swamps app executable size by a factor of about 2000.. So all this app thinning stuff seems useless (to me).

That's not universally true (as you seem to indicate already). For example, I included Google's WebRTC libraries in an iOS app and it bloated the binary by several hundred megabytes per architecture. Thinning that would help a lot.

Resources are a big part of it too, of course. A typical iOS app these days has three copies of every image, for 1x, 2x, and 3x resolutions. Dropping that down to one copy on the device is helpful. Of course this doesn't require any of this bitcode stuff, although neither does thinning the executable.

FFmpeg on Android also tends to make apps ridiculously huge when needed due to the need to support multiple architectures. Worse if you want something like x264 as well.

Well-optimized, lean apps often use cache and registers more efficiently. This brings performance boosts. That can save real $$$ on hardware or just let you do more with it.

Reply on news.ycombinator.com