Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple’s Bitcode Telegraphs Future CPU Plans

medium.com

Post reply on HN
Print view View original

21–30 of 101 posts

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#21

Post by hundchenkatze »

exelius wrote: post #8

How does dynamic linking work in a scheme like this? Would any pre-compiled libraries need to be distributed as Bitcode as well? Due to the concerns above, IMO Bitcode is less about compatibility and more about app thinning. It's pretty easy to go from Bitcode to 4 different variants of ARM; but another entirely to go from Bitcode to x86 and ARM. Currently, developers have to ship binaries compiled for multiple archi…

Yeah, according to Apple "If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode."

https://developer.apple.com/library/prerelease/ios/documenta...

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#22

Post by mikeash »

RayDonnelly wrote: post #19
exelius wrote: post #9

Earlier quoted context omitted.

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 Ap…

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.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#23

Post by twoodfin »

drfuchs wrote: post #14

I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU architecture?" But, "No; think more along the lines of 'adding a new multiply instruction'. By the time you're in Bitcode, you're already fairly architecture-specific" says he. My hopes for a return to big-endian are dashed. [Quotes are approximate.]

That sounds about right. No radical architectural shifts, but bitcode submissions should let Apple optimize apps automatically for whatever latest tweaks are available in issue width or fused instructions.

My most radical speculation is an iPhone A-series chip with an additional low power ARM core especially to support Watch apps without burning too much "host" device battery.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#24

Post by Ruud-v-A »

Microsoft has been doing a similar thing with [.NET Native](https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx) for a while now, though MSIL is much higher level than LLVM IR. With .NET Native, you _can_ submit your app once an run on ARM and x86, 32-bit or 64-bit.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#25

Post by lnanek2 »

mikeash wrote: post #22
RayDonnelly wrote: post #19

Earlier quoted context omitted.

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 i…

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.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#26

Post by spitfire »

monocasa wrote: post #10
spitfire wrote: post #6

Earlier quoted context omitted.

Sounds somewhat similar to the IBM AS/400 (renamed many times). Applications were shipped as byte code and translated to the local machine architecture. The translated byte code was appended to the application, a but like NeXT fat binaries or OS-X's universal binaries. The native byte code was 64bit, though iirc the first implementation used a 32bit address. The result was you could ship an application once and when…

Actually AS/400 byte code has 128 bit pointers. It was originally implemented on a 48 bit processor (weird 70's architectures FTW!).

I stand corrected. Thanks.

AS/400 had some really cool technology built into it.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#28

Post by kmicklas »

drfuchs wrote: post #14

I managed to ask Chris Lattner this very question at WWDC (during a moment when he wasn't surrounded by adoring crowds). "So, you're signaling a new CPU architecture?" But, "No; think more along the lines of 'adding a new multiply instruction'. By the time you're in Bitcode, you're already fairly architecture-specific" says he. My hopes for a return to big-endian are dashed. [Quotes are approximate.]

Why on earth would you ever want to _return_ to big-endian?

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#29

Post by azakai »

chuckcode wrote: post #27

Note that gcc considers their monolithic design a feature to encourage companies to contribute back code rather than a painful lesson to be learned from... http://gcc.gnu.org/ml/gcc/2004-12/msg00888.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html

The article was talking about the Bitcode design in LLVM, not the plugin situation. Yes, gcc considered making plugins hard a feature, but as for a design that separates the frontend and backend in order to make each more modular, then gcc in fact does have such a thing, gimple,

https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html

I'm far from an expert, but from what I've seen and heard, gimple is pretty good for what it does. In other words, the author of the article is wrong to say that LLVM learned from a painful lesson in this area.

Re: Apple’s Bitcode Telegraphs Future CPU Plans

#30

Post by tomjakubowski »

DannyBee wrote: post #16
stcredzero wrote: post #4

With Bitcode, Apple could change OS X into something like the old TAOS jit based OS. Except for a small kernel, all TAOS executables were intermediate representation files. This IR could be translated to real machine code at the same speed as disk access, and resulted in code running at 80-90% native speed on most platforms. With software like that, Apple could become independent of any particular software architectu…

"With software like that, Apple could become independent of any particular software architecture. " Not with the languages they use :) Neither C, nor C++, nor swift, can be made portable to new architectures through bitcode. At least, not without language-level changes to each of them. For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime"…

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc.

What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? It would seem useful for me for LLVM IR to retain some platform-dependent types like size_t or intptr_t (deferring until final translation from bitcode to machine code), but maybe that would inhibit certain optimizations.

Post reply on HN