Apple Silicon: The Complete Guide

[Anarchy99]

If I understand correctly, apps submitted to the App Store these days are uploaded with bitcode, a sort of semi-compiled non-architecture-specific copy of the code, which Apple can finish compiling for various platforms, complete with architecture-specific optimizations. They use this to be able to download only an x86 (32-bit) version or x86_64 (64-bit) version of the application to a customer, as needed, rather than having to have "fat binaries" on everyone's system (which contained all possible versions of the executable code). (I think they also did this for 32-bit vs. 64-bit iOS apps.)

There's nothing that says they couldn't use this same system in the future to automatically compile/deliver both Intel and ARM-specific versions of an app, from the same resources and bitcode, without the developer having to go through any special steps.

this isnt wrong,but my worry is with the PPC to x86 switch all the dedicated Mac Dev's did just that moved over and the tweaks to xcode and innovations Apple implemented were fine.

but many borderline Mac developers said its cheaper to not use Xcode, use wine/cider, QT etc. other things that were a cost savings because they ddnt need a dedicated mac Dev team anymore so fundimentally with the last switch we lost developers overall but didnt notice a loss in quantity because we moved from a less popular architecture to a more mainstream one.

my worry with an abrupt change to ARM would be we are doing the opposite moving from the popular architecture to the less popular one and mac market share worldwide hasn't drastically changed (there is the wildcard of a lot more apple devs because of iOS though)
that said Apple also appears less mac centric than they were in 2005 thanks to iOS so I see this being a net negative for a lot longer despite bitcode and xcode improvements.

just one more reason i think a hard switch to ARM is less optimal than a co-processor transitional period.

 

[Yoms]

macOS and iOS use pretty much the same OS kernel. The rest of the upper OS layers were made multi-platform ISA-agnostic for the PPC to Intel switch long ago. So there is no big challenge. Unix(non-TM) on ARM is trivial, zillions of ARM CPU Raspberry Pi's have been sold and run Linux and Unix apps.

Interesting comment. Thanks.

 

[CarlJ]

" The only professionals that still use macOS SHOULD be the ones that are using FCPX and Logic Pro"

And Xcode. iOS developers still constitute the largest base of professional users for Apple's ecosystem.

There are a lot of people who use Macs because they're the best Unix workstation commercially available these days - you get a polished GUI that you don't have to tweak, and you get every bit of the hardware fully supported by the OS out of the box. And lots of interoperability with iPhones and such. And lots of commercial software (Photoshop, etc.) "Just Works". And you can open terminal windows to real Unix shells all day long. I'm a software developer, but not a Mac developer, and I'd be pretty cranky if you tried to replace my Mac workstation with a Windows or Linux machine. I also know quite a few scientists who have a similar viewpoint. And very few of us run FCPX or Logic Pro or Xcode.

 

[cajun67]

RISC vs CISC... wasn't that a battle from the 90's, with PowerPC heading towards RISC design and Intel stuck in CISC?

and IIRC, Intel basically created the Pentium line to be a hybrid of RISC and CISC (best of both worlds).

 

[Morky]

RISC vs CISC... wasn't that a battle from the 90's, with PowerPC heading towards RISC design and Intel stuck in CISC?

and IIRC, Intel basically created the Pentium line to be a hybrid of RISC and CISC (best of both worlds).

Totally, long dead. The architectures basically merged over time taking the best of both.

 

[smulji]

There are a lot of people who use Macs because they're the best Unix workstation commercially available these days - you get a polished GUI that you don't have to tweak, and you get every bit of the hardware fully supported by the OS out of the box. And lots of interoperability with iPhones and such. And lots of commercial software (Photoshop, etc.) "Just Works". And you can open terminal windows to real Unix shells all day long. I'm a software developer, but not a Mac developer, and I'd be pretty cranky if you tried to replace my Mac workstation with a Windows or Linux machine. I also know quite a few scientists who have a similar viewpoint. And very few of us run FCPX or Logic Pro or Xcode.

Thanks for the insight!

 

[CaTOAGU]

You're backwards.

Microsoft and Google have nothing to compete with Apple. Windows on ARM isn't the holy-grail people think it is and Chrome - well that's a useless pretend OS.

This. Chrome is a cut down os. Windows is all things to all people. There is no need whatsoever for Apple to copy the path of either.

 

[oneMadRssn]

That's why adobe went all in on subscription based license. They don't want to support multiple version of old software on different platform anymore and give user a benefit of always using latest version at same price they paid for one version.

And BTW PhotoShop already runs on iPad so it's proven working. Not all features are there now but the foundation is here and features are much less a issue compared to the engine of the software.

Adobe is just one example though. There are several dozen software companies that make extremely important software that aren't anywhere close to anything on ARM (most of those aren't on macOS either, so it's a bit moot when it comes to Apple anyway).

 

[persuasiveghost]

First, the article is a bit confusing. ARM is not the opposite of Intel.

ARM is company that develops several different architectures / instruction sets. Many companies design ARM-licensed or ARM-compatible chips, and many other companies make them. For example, the A13 is a 64-bit ARM architecture chip manufactured by TSMC but designed by Apple.

Second, I think one of the biggest assets to macOS currently is that it can run pretty much all x86/x64 Linux apps, and most x86/x64 Windows apps can be ported over to macOS relatively easily. If they switch to ARM architecture with backwards compatibility, macOS will suffer greatly.

Windows RT failed because it lacked apps. Windows 10 on the Surface Pro X can emulate 32-bit x86 apps, and support for x64 is coming soon supposedly. If that ARM fork of Windows 10 is to be successful, it will be because of the emulation. Apple has to do the same thing, or it will surely fail.

And before someone says "but devs can just port their ARM iOS/ipadOS apps over to macOS," they can, but (1) usually iPad apps are inferior to the current x86-based macOS counterparts, and (2) so far, there have been no good ported apps.

Maybe Apple can dip their toes in the water, like Microsoft is doing, and release a ARM-based Macbook or something, but keep the Air/Pro and iMac lines on x64.

Frankly, I'd rather see Apple use the new 7nm TSMC-made AMD Ryzen CPUs.

Firstly, I want to thank people such as yourself for contributing to productive conversations while educating some of us beyond what is provided in the article. Secondly, I agree with your thoughts on keeping the x64 processors on the higher-end Mac lines. Based on my shallow understanding of RISC processors, this article, and your input, I believe that CISC is still a better option for users of more complex tasks.

 

[Unregistered 4U]

And very few of us run FCPX or Logic Pro or Xcode.

Good point, I was improperly conflating professionals with “high performance users”... the folks that will be in line buying a Mac Pro as soon as it’s available. I would hope that someone’s not buying one to run open source software that could run on ANY platform, because performance per dollar isn’t in Apple’s favor. BUT, if someone has the money, and that’s their preference, then I’m not standing in the way of them being happy

 

[theluggage]

For starters, macOS Arm means the end of VMware/Parallels/Docker/Other hypervisors. All of those rely entirely on the virtualization functions baked into in the CPU. No Arm CPU is going to be able to offer x86 virtualization support that's necessary to run virtual machines on the macOS system.

I'm using AWS ARM servers. They are pretty good at virtualizing ARM platform. So virtualizing Windows ARM64 is possible and there's an Apple virtualization hypervisor shipped with macOS right now.

- ARM64 absolutely has virtualisation functions (see here)
- But It's ARM virtualization - it creates virtual ARM machines that won't run x86 code.
- But Linux for ARM64 is already well developed, most of the major distros have a version, with most of the well-known open source packages ported.
- Parallels/VMWare won't run without a major re-write, whoch is unlikely unless its worth their while to produce a version for ARM Windows or ARM Linux
- I daresay someone will port QEMU which does both regular virtualization and software emulation (so that might run x86 code, but not fast...)
- MacOS has a native hypervisor framework and there's no reason to think that Apple won't port that (its pretty much a tick box for a modern OS). As it is, its not a replacement for a full hypervisor like Parallels or VMWare, but it would be a head start for someone wanting to make a user-friendly interface for it to support ARM Linux.
- Docker isn't a hypervisor - its a container host that provides OS level virtualisation which isn't the same thing as Parallels/VMWare. However, it does need Linux, so on MacOS and Windows it uses a single, headless VM running Linux. The current MacOS version uses the MacOS hypervisor framework (it used to use VirtualBox).
- Docker absolutely works with ARM Linux - but any binary software in the containers needs to have been built for ARM64. However, rebuilding software from source is bread and butter for Linux folk and (as noted above) most of the usual suspects (Apache, NGENIX, Node.JS, Python, PHP, MySQL, Mongo...) are already on ARM64.

Bottom line: running x86 Windows and Linux on a Mac could be painful on an ARM Mac as it would need software emulation, which would be a flashback to the good old days of SoftWindows. By Bye Bootcamp, too (at least for x86 OSs). That would probably be the major downside of an ARM Mac. That's certainly going to be a deal breaker for some, but maybe not as many as it was 10-12 years ago when every Tom, Dick and Harriet needed Internet Explorer 6 to get onto their work intranet or online banking.

Even for testing websites or apps on Windows, I'm finding its getting to the stage where if it works on Chrome/Firefox for Mac it probably works on Chrome for Windows (and, going forward, the default Windows browser is going to be the new Chromium-based Edge) Last couple of web app "bugs" I found when testing under Parallels actually turned out to be Parallels problems... and what I really need is not a VM but a Surface Pro so I can test things on a touchscreen. While development of native, binary-distributed software for Windows or Linux isn't going away anytime soon, I'm not sure how big it is on Apple's radar.

However, one door closes and another door opens: there's a lot of interest in ARM as a server platform (because energy) and a laptop/desktop that could virtualise ARM Linux could be very useful for some. A lot of web (and other) development is now being done in Node.js, Python etc. and is processor independent (...esp. when everything is 64 bit, little-endian) so what mainly helps is running the same distro as your target so everything is in the same place. Where there is binary stuff you're increasingly going to need to compile and test both x86 and ARM versions.

Of course, its also 2019 and that means you can spin up whatever flavour of x86 or ARM Linux you need and don't have somewhere in the cloud for $5/month.

That said, Apple have just launched a new Mac Pro built around Intel Xeon that is probably going to cost $10k+ for a sensible system, that isn't even in the shops yet. If they announce a total transition to ARM in a few months that's not gonna be a good look. I'd quite like an ARM Mac, but not as an only machine just yet, and I suspect the days of Intel Macs are, at worst, coming to a middle.

 

[DanBig]

a lot of people are very much in favor of arm based macs. i get the feeling a lot of them are casual users who also game. i wonder if they realize that it will be much harder to get games on the mac once they run on a proprietary niche platform compared to windows machines.

Agreed the hype train is out of step with the reality!

There will likely be a iPadOS clam-shell, not a MacBook! iPadBook maybe!

Apple would be crazy going to far here too quickly! Even if Apple thinks it can do this, there won't be as much an improvement as people think over Intel.

iPadOS is a very light-weight OS Vs macOS! As soon as you load up a full macOS onto an ARM chip a lot of the performance gains will be lost. The complexity of the application would then be the next biggest factor. And lastly virtual machine constructs would be an issue. You won't be running CISC based Windows on it.

I'm not against newer architectures, this is not what I would run with as a serious processing engine RISC-V might be the next architecture for the professional market.
[automerge]1573085905[/automerge]

Is there any data that shows that Apple’s A12/A13 chips are bad at “race up a mountain”? I’m a newbie but I understand that a drag race and a race up a mountain is different. I’m just curious to see some data.

Good question! The limits of the implementation within an iPhone or iPad makes it hard to push the chip before it thermally throttles. Basically it just conks-out somewhere on the mountain, where Intel or AMD cooling lets it keep climbing.

 

[itguy06]

There are a lot of people who use Macs because they're the best Unix workstation commercially available these days - you get a polished GUI that you don't have to tweak, and you get every bit of the hardware fully supported by the OS out of the box. And lots of interoperability with iPhones and such. And lots of commercial software (Photoshop, etc.) "Just Works". And you can open terminal windows to real Unix shells all day long. I'm a software developer, but not a Mac developer, and I'd be pretty cranky if you tried to replace my Mac workstation with a Windows or Linux machine. I also know quite a few scientists who have a similar viewpoint. And very few of us run FCPX or Logic Pro or Xcode.

You should check out what MS is doing with Linux and WsL these days. You can run a Linux distro right inside Windows. It's pretty much fully functional and interacts with the OS very well. The new Windows Terminal is also very good and can open up a real BASH or other shell right from within Windows.

I never thought I'd say this but MS is innovating and being much more open than Apple these days.

 

[Unregistered 4U]

I agree with your thoughts on keeping the x64 processors on the higher-end Mac lines.

IF... and admittedly a big IF... IF Apple can produce a system utilizing an ARM processor that can run macOS and FCPX and Xcode and Logic Pro (and other pro apps) better than Intel, then “higher-end” automatically becomes ARM... except for folks that mainly use macOS as a “virtualization host”.

 

[firewood]

The limits of the implementation within an iPhone or iPad makes it hard to push the chip before it thermally throttles. Basically it just conks-out somewhere on the mountain, where Intel or AMD cooling lets it keep climbing.

That’s just because PCs have big heat sinks and fans. Put a good sized Peltier cooled heat sink on the back of an iPad behind the A12x, and it will run tons longer without throttling.

 

[Sweetsauce]

My dumb ass thought the headline meant a Mac with a literal arm, like the iMac G4, rather than an ARM processor.

 

[DeepIn2U]

i know this forum is oddly excited about this idea, but i would much rather apple keep the higher tiers with intel processors.

It's a mildly informative posting ... YET it completely forgets Apple's long history and experience in coding for RISC based CPU's: G3, G4, and G5 ALL where based on RISC instruction set.

Do you recall the 2yrs of performance hit Apple products had back in 2006 before we got on-par or better performance? Do you recall that the final G5 was still being made at 130nm!? Imagine similar and up to date power and performance at a MUCH lower watt of say 7w tdp for desktops!
[automerge]1573106091[/automerge]

First, the article is a bit confusing. ARM is not the opposite of Intel.

ARM is company that develops several different architectures / instruction sets. Many companies design ARM-licensed or ARM-compatible chips, and many other companies make them. For example, the A13 is a 64-bit ARM architecture chip manufactured by TSMC but designed by Apple.

Second, I think one of the biggest assets to macOS currently is that it can run pretty much all x86/x64 Linux apps, and most x86/x64 Windows apps can be ported over to macOS relatively easily. If they switch to ARM architecture with backwards compatibility, macOS will suffer greatly.

Windows RT failed because it lacked apps. Windows 10 on the Surface Pro X can emulate 32-bit x86 apps, and support for x64 is coming soon supposedly. If that ARM fork of Windows 10 is to be successful, it will be because of the emulation. Apple has to do the same thing, or it will surely fail.

And before someone says "but devs can just port their ARM iOS/ipadOS apps over to macOS," they can, but (1) usually iPad apps are inferior to the current x86-based macOS counterparts, and (2) so far, there have been no good ported apps.

Maybe Apple can dip their toes in the water, like Microsoft is doing, and release a ARM-based Macbook or something, but keep the Air/Pro and iMac lines on x64.

Frankly, I'd rather see Apple use the new 7nm TSMC-made AMD Ryzen CPUs.

Unless Craig did something when the re-branding of OSX to 'macOS' was done in the core Kernel or with the original intention of OSX (to take Apple into the future for the next 20yrs; we're nearing that 20th year end of next year people) ... then OSX should BE "processor and platform agnostic".

Apple will have work to do, with the top layers ... but I'll bet something MUCH MUCH more powerful and seamless is coming other than just porting macOS to a new (yet very familiar to Apple, G3-G5, instruction set).

Swift coding language and unification of macOS and iPad OS apps,
HUGE strides in ARM based cpus (or 'influenced')
and nearing OSX's original 20yr plan.

Something REALLY big is coming from Apple ... not sure how sophisticated but it's coming.

 

[Analog Kid]

There are a lot of people who use Macs because they're the best Unix workstation commercially available these days - you get a polished GUI that you don't have to tweak, and you get every bit of the hardware fully supported by the OS out of the box. And lots of interoperability with iPhones and such. And lots of commercial software (Photoshop, etc.) "Just Works". And you can open terminal windows to real Unix shells all day long. I'm a software developer, but not a Mac developer, and I'd be pretty cranky if you tried to replace my Mac workstation with a Windows or Linux machine. I also know quite a few scientists who have a similar viewpoint. And very few of us run FCPX or Logic Pro or Xcode.

Don‘t the endless debates about who qualifies as a professional make you want to hit hit hit hit hit hit someone?

I suppose that would have been easier to write on my Mac...

 

[bjet767]

From a coding standpoint Apple can make it totally seamless for the developer to write for either the Intel or ARM CPU. The work comes in how the OS executes the compiled file. I have no idea how OSx runs a program these days. Done right the OS could easily run executable files (programs) written for either CPU based hardware. But it will require a large rewrite of OSx and the maintenance of essentially two versions to be compatible with earlier Macs.

Of course Apple has the money and the staff. The only things which may slow them down is all the hierarchy such a huge Corporation has.

 

[0837990]

Apple designs 100% custom cores that are compatible with the ARMv8 instruction set. The same way that AMD designs 100% custom cores that can run x86. Do you think AMD simply uses Intel “parts” and slaps them together? Ridiculous.

Apple still designs ARM chips based on ARM's core technology. Apple didn't invent ARM. And if ARM suddenly decides to stop licensing it's technology, Apple couldn't proceed with anything based on ARM core technology. And yes, AMD (and Intel also) DOES actually use "parts" from each other and slap them together. AMD and Intel has for a very long time (and still has) a full cross-licensing agreement, which enables them to use whatever tech the other company has developed. And they do.

 

[UpDown]

As an enterprise developer, an Arm CPU in a Mac would be a disaster. I use Xcode for iOS development, Android Studio for Android development, Eclipse for Server side development, VMWare running Linux and Windows, and Docker containers. Lots of threads, lots of RAM. Intel is the best option here. There's no way that Apple would be able to emulate X64 on an Arm64 CPU, and if they could its performance would be appalling.

If it did happen - Xcode would work on an Arm chip, and you'd be able to run iOS apps. Android Studio is not Apple's concern... nor Eclipse, but I've never come across an Android developer yet running on Windows or Linux. Anyhow, you'd need Oracle to provide a decent Arm64 based Java JVM. And it won't be Java 8, it'd be some new fangled Java version (12?) that no one runs in the enterprise. Won't be able to run VMWare to run Windows or Linux. Our docker containers run Intel compiled software not Arm, as that's whats deployed on the servers. Makes no sense to run a Arm compiled app in a docker container for development and then recompile to Intel to run on a server. Defeats the point of a docker container for portability.

In terms of CPU's, the Apple Bionic System-On-A-Chip's contain CPU and stacked RAM. Do you think they could stack 64GB of RAM in there? No. They'd have to make the chip die physically larger to be able to add in external RAM etc. What about Thunderbolt 3 support? Making a desktop/server class chip for Mac's tiny single digit marketshare? Not going to happen, the cost is too great for the little return, it just doesn't make any sense.

 

[d3vi1]

As an enterprise developer, an Arm CPU in a Mac would be a disaster. I use Xcode for iOS development, Android Studio for Android development, Eclipse for Server side development, VMWare running Linux and Windows, and Docker containers. Lots of threads, lots of RAM. Intel is the best option here. There's no way that Apple would be able to emulate X64 on an Arm64 CPU, and if they could its performance would be appalling.

If it did happen - Xcode would work on an Arm chip, and you'd be able to run iOS apps. Android Studio is not Apple's concern... nor Eclipse, but I've never come across an Android developer yet running on Windows or Linux. Anyhow, you'd need Oracle to provide a decent Arm64 based Java JVM. And it won't be Java 8, it'd be some new fangled Java version (12?) that no one runs in the enterprise. Won't be able to run VMWare to run Windows or Linux. Our docker containers run Intel compiled software not Arm, as that's whats deployed on the servers. Makes no sense to run a Arm compiled app in a docker container for development and then recompile to Intel to run on a server. Defeats the point of a docker container for portability.

In terms of CPU's, the Apple Bionic System-On-A-Chip's contain CPU and stacked RAM. Do you think they could stack 64GB of RAM in there? No. They'd have to make the chip die physically larger to be able to add in external RAM etc. What about Thunderbolt 3 support? Making a desktop/server class chip for Mac's tiny single digit marketshare? Not going to happen, the cost is too great for the little return, it just doesn't make any sense.

100% rubbish. The ARM64/ARMv8/aarch64 transition has already started. RHEL is there. Windows is there. Darwin is there. Now let's take some of your claims for a run:
1) Lots of RAM is only a problem if you want to package it stacked on top of the CPU, just like in the iPhone. That is probably not the route for a laptop of desktop class system.
2) VMware has already done demos of ESXi on ARMv8. Their virtualization engine works on ARMv8, so Fusion can't be far behind.
3) QEMU runs on ARMv8 brilliantly.
4) OpenJDK runs on ARMv8 without a problem. So Eclipse should work flawlessly. Why would Oracle's JVM be a must?
5) ARMv8 CPUs beat the living sh*t out of Intel CPUs in performance per W. At the same power and thermal levels that you get in a normal laptop, an ARM chip should be 30% faster in single threaded and have at least double the cores compared to the flagship Intel CPU. Considering that right now the power management in Apple's CPUs is the best available, the margins might be even bigger. These are not small increases, these are doublings of performance. The current MacBook Pro laptops use 30W-60W TDP for CPU, Chipset and GPU. The current iPad Pro uses 6W for comparable performance. There is exceptional room for growing on the Macs.
6) Windows runs on ARMv8. Linux runs on ARMv8.
7) Thunderbolt is a PCI-E device. The storage on the IPhone is NVMe over PCIe. Since the A11+ chips already provide PCIe, why wouldn't they put an existing Thunderbolt controller on the motherboard?
8) It also makes great economical sense, considering that an iPad Pro is fundamentally 90% of an Apple Laptop. It needs the following extras: Thunderbolt controller, more RAM and CPU/GPU scaled to laptop-class, so the board designs would have a lot of common items. Single firmware for all platforms (iBoot) also makes sense. Not having to maintain NVidia, AMD and other 3rd party drivers and just including the AppleWireless and AppleGPU kernel extensions is also economical.

The only place where you might have some performance issues with the ARMv8 transition is running pre-existing x86 Windows applications in a virtualized ARM Windows 10. Microsoft already has you covered (32-bit x86 only), but with some performance penalty.
[automerge]1573128728[/automerge]

From a coding standpoint Apple can make it totally seamless for the developer to write for either the Intel or ARM CPU. The work comes in how the OS executes the compiled file. I have no idea how OSx runs a program these days. Done right the OS could easily run executable files (programs) written for either CPU based hardware. But it will require a large rewrite of OSx and the maintenance of essentially two versions to be compatible with earlier Macs.

You do realize that iOS and macOS are the same operating system? Sure, they use a different GUI, but the OS is the same. That means that the kernel, daemons, libraries, compilers and everything else are already there and have been so for a very long time. No rewrite is necessary, just like with the transition from PPC to Intel.
There was a lot of hype about the secret project of running Mac OS X on Intel, but that was just marketing. The open source part of the OS (which was almost everything except Finder and WindowServer) was downloadable as darwin-x86 since the early days of Mac OS Server. Actually, ever since NeXTStep 3, the x86 builds have always been available and public in both the NeXT era and the Apple era (remember Rhapsody?).
Same with the ARM64 transition. Apple can create a build of macOS for testing on the iPad any time they want.

 

[UltimaKilo]

Let’s hope never. This would be a disaster for power users who are looking forward to Tiger Lake MBPs.

 

[Nugget]

100% rubbish. The ARM64/ARMv8/aarch64 transition has already started. RHEL is there. Windows is there. Darwin is there.

Wow, you and I have very different definitions of "there." Windows for Arm is an unmitigated disaster and the vast, vast, vast majority of production systems on the planet are running x86 hardware and containers with Arm's market penetration way down in the low single digits with an indiscernable growth curve.

As an enterprise software developer building software for on prem and cloud deployments, my work product is going to be x86 docker containers (for Kubernetes running on Intel kit) for at least the next five years. One hundred percent of our in house infrastructure is x86. One hundred percent of our cloud resources are x86-based and we're not even talking about experimenting with Arm.

If I can't keep doing that work with macOS then I'm going to have to move to a different platform. macOS on Arm would be the end of the road for me.

 

[IG88]

Apple just patched the ARM parts they wanted together, and outsourced the manufacturing to TSMC.

If it's that simple, then Apple ARM CPUs shouldn't be stomping the daylights out of Qualcomm's ARM CPUs.