This article is more than 1 year old
Apple Arm Macs ship, don't expect all open-source apps to work without emulation – here's what you need to know
Good thing Rosetta 2's x64-to-ARM64 translation is all right because you may be using it a lot
Mac hardware based on Apple's M1 chip has started showing up on early adopters' doorsteps, and the machines appear to perform well, even when the 64-bit Arm-based devices are emulating x86_64 instructions using Apple's Rosetta 2 emulation layer.
Geekbench scores show M1 Macs outpacing prior Intel-based models by a good margin in single-core tests. And the newly released M1-based MacBook Air emulates x86_64 code with Rosetta 2 faster than Intel-based Macs run native applications, again in single-core tests. Your mileage may vary with multi-core. Beyond Apple's line-up of Macs, the M1 is beaten by certain Intel and AMD processors.
The M1 features four high-power ARM64 CPU cores clocked up to 3.2GHz, and four efficiency cores at about 2GHz. The big four, dubbed the Firestorm cluster, each have 192KB of instruction cache, and 128KB of data cache, which is a lot, and share a 12MB L2. The four smaller ones, dubbed Icestorm, have a 128KB instruction cache each, 64KB of data cache, and a shared 4MB L2. The TSMC 5nm chip comes with 8GB or 16GB of RAM built-in for the system.
Unfortunately, those planning to do work on the initial set of M1 Macs may have to settle for running their apps under Rosetta for several months. While Apple made sure its own macOS Big Sur apps were ready, more than a few open-source projects and commercial apps have yet to be rebuilt with ARM64-based code and thus will rely on the translation layer.
Microsoft has released a Universal build – containing x86_64 and ARM64 binaries – of its Mac Office 2019 beta. But there's not yet an M1-native general release of Office. Similarly, Microsoft's popular code editor Visual Studio Code has an experimental ARM64 build, with a Universal build planned for the end of this month.
Adobe, historically known for being out of step with Apple during platform transitions, has a beta version of Photoshop for Apple Silicon available and plans a native version of Lightroom by the end of 2020. But it hasn't published a timeline showing when the rest of its apps will get native Apple Silicon builds.
Apple drops macOS Big Sur on the world – and it arrives with a thud, sound of breaking glass, sirens in the distance...
READ MOREGoogle on Tuesday shipped Chrome 87 with Apple Silicon support, though it appears the browser's built-in Widevine DRM system still relies on Rosetta translation.
And for those hoping to run native versions of professional creative apps other than Apple's, don't expect too much. Avid, for example, is still working on delivering Intel support for macOS Big Sur for apps like Pro Tools and Media Composer.
Anyone wishing to run Windows on an Apple Silicon Mac is also out of luck: Apple's Boot Camp technology for booting Mac hardware into Windows isn't available under the new regime. And the promised new virtualization layer for Apple Silicon hardware has yet to officially arrive, leaving ARM64 versions of VMware Fusion and Parallels as works-in-progress for the time being. Oracle has been silent on whether it will port its VirtualBox hypervisor to the M1.
Docker, widely used by developers, is another no-show. Though it's being tuned to run on M1 hardware, it depends on other open-source projects like the Go programming language and the Electron cross-platform app framework.
In a blog post on Monday, Benjamin De St Paer-Gotch, principal product manager at Docker, explained that Docker runs a virtual machine under Docker Desktop, a capability that won't be available until Apple releases its virtualization layer and Docker adapts its code.
"[W]e have technical dependencies upstream of us that need to make changes prior to making a new version of Docker Desktop GA," he said. "We rely on things like Go for the backend of Docker Desktop and Electron for the Docker Dashboard to view your Desktop content."
Golang is currently aiming for Apple Silicon compatibility in February, with the Go 1.16 release.
The Rust programming language team offers a tier-2 cross-compiler that outputs native Arm code suitable for running on an M1 Mac.
Electron, meanwhile, added Apple Silicon support in version 11.0.0-beta.1 last month and in subsequent builds. Version 12.0.0 is due on November 19.
Samuel Attard, a senior software engineer at Slack and one of the Electron project's maintainers, advised Electron devs to include a native ARM64 binary in app builds. While x86_64 Electron apps will run under Rosetta 2, he explains, "performance will be significantly degraded."
The macOS package manager Homebrew also has yet to make the transition to Apple Silicon, thanks to unresolved issues in many of the packages it handles. About a dozen of these packages including Gradle, Maven, and Jenkins are listed as waiting for Apple Silicon support in OpenJDK, which has just arrived. But many other open source projects haven't made the leap.
The GCC compiler has yet to receive Apple Silicon support, and that's led some to argue that anyone serious about scientific computing should avoid M1-based Mac models until the situation improves. Those behind the R programming language have confirmed the language runs well under emulation but isn't yet available to run natively on Apple Silicon because R depends on having an Apple Silicon-ready Fortran 90 compiler.
"A usable Fortran 90 compiler for Apple Silicon will hopefully be available relatively soon, since the development version of GFortran already seems to be working ... and there is a strong need for such compiler not only for R, but any scientific computing on that platform," said R core team members Tomas Kalibera and Simon Urbanek, in a blog post earlier this month.
The situation is similar with the Julia programming language. Despite Apple's promise to provide Apple Silicon patches for about 30 open source projects, there's still a lot of work to be done. ®
Biting the hand that feeds IT
