domeet webmaster

This article is from WeChat official account:InfoQ (ID: infoqchina), compilation: Tina, nuclear cola, title picture from: Apple “One More Thing” conference

Apple’s core change operation

In the early morning of November 11th, Apple’s “One more thing” conference came as scheduled. At the press conference, Apple announced the launch of its first self-developed 5nm M1 chip, which will power its new generation of ARM-based Mac products. Apple claims that this M1 chip is equipped with many world-class products, including the world’s fastest CPU core and fastest IGPU.

“Apple has spent more than ten years creating and optimizing the Apple chip, because the chip is the core of the iPhone, iPad and Apple Watch. Now we want to introduce it to the Mac, so the Mac can rely on incredible performance, Custom technology and industry-leading chips to achieve a huge leap.” Apple official said.

Apple believes that the M1 is the highest performance chip to date, and the low-power, high-efficiency core can provide performance similar to the current Intel-based dual-core MacBook Air. Of course, high-performance cores are much faster.

Before the M1 chip was launched, Intel almost monopolized the CPU of Apple’s notebook computers. In 2005, Apple switched from the PowerPC chip to Intel. This transition has been 15 years, and the cost of the transition mainly comes from software. At the beginning, developers need to use the toolchain provided by Apple to generate universal binaries that can run on PPC and x86 Mac, and not all Apple’s previous APIs can be transitioned to x86.

Rosetta

Back then, Apple launched a tool chain called Rosetta, which was used to convert PowerPC applications to x86. Rosetta can make most PowerPC Mac OS X applications run on x86 Macs, despite some performance losses(this is not a simple matter). In the end, Rosetta became Apple’s Band-Aid, and was not abandoned until the launch of Mac OS X 10.7(Lion) in 2011.

Three solutions given by Apple

Now, switching from Intel to Apple Silicon, Apple has given three solutions: Universal 2 universal application, Rosetta 2 tool chain, native ARM application.

The first solution is to use”Universal 2″ runs applications for system software such as Adobe Photoshop and Microsoft Word. The second solution is to use the Rosetta 2 provided by Apple to recompile the application so that x86 applications can run on the ARM architecture, mainly for most lightweight applications that do not involve processor features.

In essence, Rosetta 2 may be sufficient to support most mainstream productivity applications, but it is often not compatible with software that requires direct interaction with operating systems, hardware, or graphics hardware. In particular, those users who involve virtualization or high-end graphics, video or scientific application processing in mission-critical requirements may best wait for the launch of the native software version before considering upgrading to the ARM-based Apple chip version of the Mac platform.

The problems caused by core replacement for developers

Obviously, this core replacement operation will bring huge benefits to consumers, including obtaining longer battery life and improving overheating problems( The 2018 MacBook Pro is a powerful “warm baby”). The tight integration between software and hardware will also further optimize the user experience. In addition, product prices may also fall.

Apple’s chip migration decision naturally aroused the concerns of developers, especially in terms of developer experience. Although Apple said that it has provided corresponding solutions, emphasizing that the new chip will increase the productivity of developers, but the core change will also deal a heavy blow to professional developers who are highly dependent on its products and ecosystem.

Existing Mac apps may slow down

If existing Mac applications are recompiled into “Universal 2” binary form with the help of the Rosetta 2 conversion engine, most of the 64-bit MacOS applications written for Intel processors can run directly on the Apple chip version of Mac on.

But Apple jokingly mentioned in the developer documentation: “The translation process takes time, so users may feel that the translated application occasionally slows down when it starts or runs.” p>

Of course, as long as any form of simulation, virtualization or translation process is involved, the running speed of the application must be slightly slower than the native version. Although there is no official confirmation, through the leaked Geekbench 5 benchmark test, you can probably infer that the Mac mini DTK will run faster than the iPad Pro(2020)< /span>How slow on the model.

Compared with the iPad Pro(2020) model that runs native code, the Mac mini DTK is running Geekbench in a single-core form through Rosetta 2. 5 In the benchmark test, the speed was reduced by 26%; in the multi-core mode, the speed was 38% slower.

It is worth mentioning that compared with this iPad Pro, the clock frequency of the Mac mini DTK has also been reduced, and the beta software it runs has not been optimized. But if we assume that the two clock frequencies are the same and that further software optimization is completed when the final hardware is released, it is estimated that the speed disadvantage of running the software through Rosetta compared to the native application should be between 20% and 30%.

It is certain that the performance of the ARM-based Apple chip Mac is stronger, and even more than enough to offset the speed disadvantage caused by the introduction of Rosetta 2, and finally achieve the same performance level as most Intel chip version Macs a year or two ago .

But what about the others? In fact, most users who develop on Mac are not building iOS or MacOS applications.

According to the StackOverflow 2020 developer survey, more than a quarter of developers use MacOS, but only 6% of users use the Swift language. As the only official Apple ecological application building language currently designated by Apple, Swift’s weak market share is enough to show that most Mac users are not actually developing products for Apple.

In other words, quite a few developers on MacOS are building other types of applications, such as web applications running on cloud servers. For these already familiar with Node.js, Python, Ruby, PHP, Go and even .NETI plan to use a Mac to test my Windows applications, so I can only say sorry. You need to buy another laptop or use remote desktop service. In addition, you can’t run a virtual machine on a Mac for device testing(such as ESXi, pfSense, FreeNAS, etc.).

the impact of Docker

Because Docker on the Mac can only run in a virtual machine, and users can only virtualize Linux based on the ARM architecture, it means that we can only run ARM64 containers on the Apple chip version of the Mac in the future.

Currently, there are 3.31 million AMD64 mirrors on Docker Hub, but only 29,076 mirrors targeting ARM64, accounting for less than 1%. Furthermore, building a multi-architecture Docker image is particularly complicated.

In particular, it should be noted that because the production system usually runs Linux/AMD64, the binary files and Docker images you produce may not run on the development computer. Of course, you may be able to recompile and cross-compile, but you will never be able to restore its true running state. In addition, if your application has a problem in the production environment, you can’t debug it on your laptop based on binary files or container images.

Docker occupies a very important position in the daily workflow of developers, so these make developers feel quite a headache.

Docker configuration environment error

Dr. Stephen Turner, who works at Docker, said: “Although the operating system has virtualization capabilities, Apple chips do not yet support virtualization. We are powerless, but we are working closely with Apple to solve this problem.” But what When it can be resolved, he said that “there is no specific date yet.”

After the press conference on the 11th, according to the feedback from the developers, they doubted whether the problem has been resolved: “As far as I know, M1 does have virtualization support, but Docker has not yet been ported.”

And if you can only run Docker on the virtualization layer, it will cause a serious drag on file I/O performance and cause the compilation speed of large projects to plummet. Some developers said that currently he can only use docker-sync to solve this problem. In addition, unless docker machine is used to implement a real virtual machine, there is no other way to mount the device to the docker container on the Mac. Therefore, for most software vendors that need to directly interact with the hardware, it is the right way to release the native version of their software early.

Of course, you can use Rosetta 2 to run x86 containers, but it remains to be seen whether it can be further extended to support x86 operating systems such as virtualized Linux.

Referring to the 2005 transition plan, Apple gave two years for this transition. If all goes well, Apple should remove support for the x86 instruction set in the new version of macOS two years later, and Rosetta 2 in the new version three years later. In the past three years, what price developers need to pay remains to be verified.

Reference link: https://www.reddit.com/r/docker/comments/jpzt43/docker_for_mac_on_apple_silicon_keynote/

https://github.com/docker/for-mac/issues/4733

https://news.ycombinator.com/item?id=25073010