4 ms·

Apple has a tactical advantage over Microsoft and even server-side ARM like Graviton: it’s LLVM toolchain integrated into Xcode for both Objective-C and Swift.

Apple has a tactical advantage over Microsoft and even server-side ARM like Graviton: it’s LLVM toolchain integrated into Xcode for both Objective-C and Swift. Apple has a precedent for a seamless CPU architecture transition: the iPhone 64-bit transition. It is much harder to cross-compile seamlessly with traditional Gnu C or Visual Studio toolchains. The App Store requirements make it easier to control this transition on iOS than macOS. I wonder how many Brew apps will make the transition seamlessly?

woadwarrior01 6y ago
Also Bitcode[1] which was introduced 5 years ago for iOS, watchOS and tvOS. I have a feeling they'll be making app binaries built with `-fembed-bitcode` optional on the Mac App Store and eventually mandatory. [1]: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f
- scarface74 6y ago
  The idea that bitcode will allow porting from x86 to ARM was dispelled by non other than Chris Lattner himself during an interview on ATP. https://atp.fm/205-chris-lattner-interview-transcript#bitcode https://atp.fm/205-chris-lattner-interview-transcript#bitcod... John Siracusa: The same thing I would assume for architecture changes, especially if there was an endian difference, because endianness is visible from the C world, so you can’t target different endianness? Chris Lattner: Yep. It’s not something that magically solves all portability problems, but it is very useful for specific problems that Apple’s faced in the past.
  - wolfgke 6y ago
    What has endianness to do with porting from x86 to ARM? Typical ARM implementations/ABIs use little endian mode.
    - scarface74 6y ago
      The context of the answer was: John asked: And the more prosaic version: it doesn’t mean it’s CPU-agnostic, all it means is that Apple has slightly more freedom to change instructions on the CPUs that they do target? [10:30] What advantages are there of compiling something to Bitcode and then uploading it somewhere versus sending someone a binary?
  - woadwarrior01 6y ago
    You seem to be assuming that the CPU on iOS devices are running in big-endian mode. ARM CPUs support both big endian and little endian modes and ARMs on Apple i-devices have been running on little endian mode for as long as they've been around. There is no endian difference gap to bridge between ARMs on iPhones and x86 CPUs. Given this, it's quite unlikely that Apple will go big endian in their Desktop/Laptop ARM CPUs. Of course, Bitcode won't solve all portability problems, but it does solve many of them in this specific case.
    - scarface74 6y ago
      Read the transcript around the quote. It’s not just the endian differences. He said that it basically only helps with things like minor optimizations and added instructions.
miohtama 6y ago
Most of Homebrew upstream already runs on ARM Linux: Raspberry Pis, mobile phones and so on. Reworking the build process may take some time, but packages themselves should support multiple architectures.
pjmlp 6y ago
Ever heard of this little thing called .NET? Or PocketPC for that matter?
- sradman 6y ago
  I have indeed heard of both. In fact, I worked on a 3rd party product that Microsoft highlighted at the introduction of PocketPC. Some products make very specific target architecture decisions. MS Surface tablets suffered due to code that was not .net or was not possible to port easily.
AshamedCaptain 6y ago
I really don't see any "tactical" advantage. MS has similar toolchains. MS has also done a similar 32-bit to 64-bit transition. And to top it off MS has done it on a PC, and not an smartphone where people do not depend on running "random" binaries. The fact that MS has also tried several times to switch from ARM but no advantage has ever materialized also casts a huge doubt on the tactical advantages of an ARM migration. The power savings are not apparent: neither the Surface RT nor the Surface Pro X have significantly better battery life, likely because they've (very much like Apple will do) decided to reduce thickness. The performance is not there as both devices were reviewed as slow. And the cost advantage is also not there seeing that the Surface Pro X was more expensive than most of the Intel Surface Pros, at least for launch price (and we can certainly expect Apple not to lower prices, either). I am guessing MS had more margins on the ARM devices, and that's about it, but it makes for a hard sale for users. Also those margins will evaporate as they are forced to reduce the price of the SP X. Apple's previous migrations depended on the _huge_ performance improvement of the newer platform. Up to the point where porting programs to the new platform was not even always required, as the emulator would be performant enough to still show a performance improvement overall. In this case, the new platform has likely similar or slightly lower performance, and we care much more about power consumption, so emulation cost will be very noticeable and users will penalize non-native binaries heavily. Apple has the advantage of the huge collection of iOS apps but I also hesitate whether this advantage will transfer to the MacBook or not. Most people do not buy MacBooks to run oversized iPhone apps. They already have the iPad for that.

woadwarrior01 6y ago

Also Bitcode[1] which was introduced 5 years ago for iOS, watchOS and tvOS. I have a feeling they'll be making app binaries built with `-fembed-bitcode` optional on the Mac App Store and eventually mandatory. [1]: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

scarface74 6y ago
The idea that bitcode will allow porting from x86 to ARM was dispelled by non other than Chris Lattner himself during an interview on ATP. https://atp.fm/205-chris-lattner-interview-transcript#bitcode https://atp.fm/205-chris-lattner-interview-transcript#bitcod... John Siracusa: The same thing I would assume for architecture changes, especially if there was an endian difference, because endianness is visible from the C world, so you can’t target different endianness? Chris Lattner: Yep. It’s not something that magically solves all portability problems, but it is very useful for specific problems that Apple’s faced in the past.
- wolfgke 6y ago
  What has endianness to do with porting from x86 to ARM? Typical ARM implementations/ABIs use little endian mode.
  - scarface74 6y ago
    The context of the answer was: John asked: And the more prosaic version: it doesn’t mean it’s CPU-agnostic, all it means is that Apple has slightly more freedom to change instructions on the CPUs that they do target? [10:30] What advantages are there of compiling something to Bitcode and then uploading it somewhere versus sending someone a binary?
- woadwarrior01 6y ago
  You seem to be assuming that the CPU on iOS devices are running in big-endian mode. ARM CPUs support both big endian and little endian modes and ARMs on Apple i-devices have been running on little endian mode for as long as they've been around. There is no endian difference gap to bridge between ARMs on iPhones and x86 CPUs. Given this, it's quite unlikely that Apple will go big endian in their Desktop/Laptop ARM CPUs. Of course, Bitcode won't solve all portability problems, but it does solve many of them in this specific case.
  - scarface74 6y ago
    Read the transcript around the quote. It’s not just the endian differences. He said that it basically only helps with things like minor optimizations and added instructions.

miohtama 6y ago

Most of Homebrew upstream already runs on ARM Linux: Raspberry Pis, mobile phones and so on. Reworking the build process may take some time, but packages themselves should support multiple architectures.

pjmlp 6y ago

Ever heard of this little thing called .NET? Or PocketPC for that matter?

sradman 6y ago
I have indeed heard of both. In fact, I worked on a 3rd party product that Microsoft highlighted at the introduction of PocketPC. Some products make very specific target architecture decisions. MS Surface tablets suffered due to code that was not .net or was not possible to port easily.

AshamedCaptain 6y ago

I really don't see any "tactical" advantage. MS has similar toolchains. MS has also done a similar 32-bit to 64-bit transition. And to top it off MS has done it on a PC, and not an smartphone where people do not depend on running "random" binaries. The fact that MS has also tried several times to switch from ARM but no advantage has ever materialized also casts a huge doubt on the tactical advantages of an ARM migration. The power savings are not apparent: neither the Surface RT nor the Surface Pro X have significantly better battery life, likely because they've (very much like Apple will do) decided to reduce thickness. The performance is not there as both devices were reviewed as slow. And the cost advantage is also not there seeing that the Surface Pro X was more expensive than most of the Intel Surface Pros, at least for launch price (and we can certainly expect Apple not to lower prices, either). I am guessing MS had more margins on the ARM devices, and that's about it, but it makes for a hard sale for users. Also those margins will evaporate as they are forced to reduce the price of the SP X. Apple's previous migrations depended on the _huge_ performance improvement of the newer platform. Up to the point where porting programs to the new platform was not even always required, as the emulator would be performant enough to still show a performance improvement overall. In this case, the new platform has likely similar or slightly lower performance, and we care much more about power consumption, so emulation cost will be very noticeable and users will penalize non-native binaries heavily. Apple has the advantage of the huge collection of iOS apps but I also hesitate whether this advantage will transfer to the MacBook or not. Most people do not buy MacBooks to run oversized iPhone apps. They already have the iPad for that.