Docker and Apple Silicon
I have been using Docker since 2014, primarily to support web development.
Last year, I tested Docker for Mac on the MacBook Air (M1) and MacBook Pro (M1 Max) both running Apple Silicon, which I documented across four articles.
Docker running on Apple Silicon demonstrated tremendous potential. Unfortunately, the hardware was held back by the software, specifically Docker Desktop for Mac that leverages gRPC-FUSE for file sharing, which resulted in poor I/O performance.
In my testing, the best build time I could achieve running Docker on macOS was 220 seconds, compared to just 9 seconds when building under Docker via a Linux virtual machine (Ubuntu Server ARM64) running on UTM.
The I/O performance limitation is workload-specific, primarily impacting projects with a lot of small files. However, it was disruptive enough, that it forced me away from Docker Desktop for Mac.
Therefore, I have spent the past six months running Docker inside a “right-sized” Linux virtual machine, which unlocked the raw performance of the Apple Silicon by removing the filesystem I/O bottleneck. This approach delivered an unbelievable 24x performance increase over Docker Desktop for Mac.
Docker Desktop v4.6.0
Yesterday, Docker released Docker Desktop for Mac v4.6.0, which included the following new feature:
- Docker Desktop 4.6.0 gives macOS users the option of enabling a new experimental file-sharing technology called VirtioFS. During testing VirtioFS has been shown to drastically reduce the time taken to sync changes between the host and VM, leading to substantial performance improvements.
The accompanying blog post states.
“The 4.6 release of Docker Desktop for Mac contains a number of changes that drastically improve file sharing performance for macOS users. Firstly, developers now have the option of using a new experimental file sharing implementation called virtiofs (the current default is gRPC-FUSE). Secondly, improvements have been made to the way that files are synced between the macOS host and Docker VM. During testing with our amazing macOS community of users, we have observed that these changes have reduced the time taken to complete filesystem operations by up to 98%.”
In theory, this new feature directly targets the issue I have been experiencing, therefore I was eager to see how it performed across my common workloads.
Test Setup
As part of my testing, I will be using the 16-inch MacBook Pro (OCT-2021). A summary of the specification can be found below.
16-inch MacBook Pro (OCT-2021)
- Apple M1 Max (10-core - 8 Performance / 2 Efficiency)
- 32-core GPU (10.4 Teraflops)
- 64GB Unified Memory (400GB/s Memory Bandwidth)
- 1TB SSD (7.4GB/s Read)
- macOS 12.3
I plan to use LifeinTECH (this blog) as my test build, which follows the JAMstack web development architecture, using the Jekyll Static Site Generator.
The project includes a range of external dependencies and custom plugins. It is fairly large, including over 4000 individual files and 800MB of data. This is relevant as it applies file sharing I/O pressure.
On the MacBook Pro, I plan to test three scenarios, specifically Docker Desktop for Mac (default), Docker Desktop for Mac (VirtioFS), and Docker running on a Linux virtual machine using UTM.
To enable VirtioFS, update to Docker Desktop for Mac v4.6.0 or higher, select “Preferences > Experimental Features” and check the following configuration options.
- Use the new Virtualisation framework
- Enable VirtioFS accelerated directory sharing
The screenshot below highlights the configuration.
Once configured, Docker will restart with VirtioFS enabled by default.
Results
The table below highlights my findings. As a point of comparison, I have retained my original test results, which include my AMD Ryzen 3950X (16C/32T) / 64GB RAM custom-built PC running native Docker Desktop (WSL2).
I am pleased to report that the new VirtioFS file-sharing implementation does make a significant difference.
The build time dropped from 220 seconds to 38 seconds, which is also faster than my custom-built PC. It cannot compete with the Linux virtual machine using UTM, but this is essentially Apple Silicon running on native Linux, therefore removing all middleware bottlenecks.
Conclusion
In a perfect world, I would love to see “native” Docker performance under macOS, achieving the same 9 second build times achieved with Linux.
However, 38 seconds is a significant improvement over 220 seconds and it also outperforms my custom-built PC (75 seconds). This is a huge milestone and I commend the team at Docker for this release!
As a result, I believe Docker Desktop for Mac has now become viable for daily use.
Although I will likely retain my Linux virtual machine as a backup, the ability to simply build directly from macOS without any additional pre-work (UTM configuration, Ubuntu Server setup/maintenance, SSH) is highly valuable.