We've compared docker performance between Intel and M1 and the M1 falls quite a bit far behind in response times. We can't do exact comparisons due to CPU differences, but for Docker I can't say it is in a good state right now (yes we enabled the docker filesystem beta enhancement for M1). This is for x86 containers at this time.
It is much better than it was not so long ago due to actually working at all, and it appears there is much more room for optimization, so the comparison is not over yet. But as of right now, it isn't that great.
That is a strange way to put it. Rosetta 2 (and orig.) is not virtualization, it is emulation, though there is a half-decent argument that Rosetta 2 (and orig.) is not emulation either -- it is recompilation.
It’s more complex than that and the specific point being made is accurate - Rosetta 2 doesn’t support virtualisation in the sense that it cannot perform translation in the context of virtual machine.
If you run an x64 Mac binary on the host, Rosetta (simplified) translates the code to arm64 then runs it. If you run a Linux VM and execute an x64 Linux binary or container inside it, Rosetta can’t help you. You’ll be running inside a big emulator - in fact, Docker Desktop uses QEMU under the hood I think.
More accurately, Rosetta doesn't support kernel extensions, and it will not run software that virtualizes x86 machines.
But it's not as if you can't run a virtual machine native to the platform. Qemu works on M1, Parallels works on M1 (ARM VM only) and there is a preview for VMWare's Hypervisor that will run even Windows 11 on the M1, but the VM software is native code (but not necessarily the system in the VM), so Rosetta isn't used.
It’s worth noting explicitly what others have said - if you are doing what you describe, you are running your Linux containers under QEMU.
The performance of this will be terrible; there is likely little room for optimisation and you should not expect this to get any faster in the future.
Using aarch64 containers changes the game entirely. Common base images like Ubuntu are already multiarch so will just work out of the box. But this has obvious downsides and won’t be a suitable solution for everyone.
It doesn't make much of a difference. macOS Docker performance is heavily limited by really poor volume mount performance.
In one of our projects the benchmarks look like this to run our test suite for a web app using volume mounts:
- 2020 Intel MBP (10th gen CPU, 32GB of memory, SSD): 37 seconds
- First generation M1 MBP: 31 seconds
- WSL 2: 3 seconds
The WSL 2 box is an old workstation I have from 6-7 years ago with an i5 3.2ghz CPU, 16gb of RAM and one of the first SSDs. All in all it was about $800.
The WSL 2 box is so fast for Docker because the volume performance is pretty much as good as native Linux. It's really fast.
'In the real world' it isn't just Apple switching to ARM. I've been moving AWS workloads to Graviton for the cost savings. More and more default containers have both x86 and ARM available.
Well, then probably you're using fairly exotic stuff, because most widely used base images nowadays have a arm build, and for the rare cases where this is not true (usually internal company stuff) you can build it yourself.
It's also unfair to use MacOS instead of an operating system with proper container support, but sometimes "fairness" doesn't matter as much as "how the machine is going to be used"
It's actually pretty impressive how much faster Docker builds containers on M1 running in aarch Linux VM vs on Docker Desktop. But to your point about "how the machine is used", I've encountered very few devs who care.
It is much better than it was not so long ago due to actually working at all, and it appears there is much more room for optimization, so the comparison is not over yet. But as of right now, it isn't that great.