Hacker News Reader

Comment by dilyevsky | Hacker News Reader

What is arm64 container? Container is just a namespaced process so if your binary is x86 it is still technically x86 container just run using emulation. And qemu user static already does translation a la rosetta 2 so there probably wont be much difference in speed

View on HN

The whole point in providing Rosetta is because it (should) be significantly faster than plain qemu.

If by plain qemu you mean its user mode emulation then i think it remains to be seen what the performance improvement will be. User mode already can be ok if it’s not doing endianness translation

I'm gonna guess that if Apple invested this level of effort into it, it's not a "remains to be seen what the performance improvement will be". You can take their graphs and charts and sort of de-reality-distortion-field them to know that it will be much faster than qemu for the workloads Apple knows people run frequently, but still slower than if you had a new x86_64 machine.

I've done a lot of work with running userland qemu for x86_64 in aarch64 vms on macOS 12. The experience is serviceable for simple things, but if I build anything really heavyweight, I find I need a native arch builder. I have little doubt that Rosetta will be an improvement.

Docker contains a Linux kernel, does it not?

Nope, docker just sets up linux cgroups/namespaces and spawns a new linux process, no kernel of its own.

Docker Desktop (ie Docker on Mac) absolutely sets up a VM.

Correct, on macs it spawns a (usually aarch64) vm using apples hypervisor framework api (hw virt) and runs docker daemon inside of it. Then it’s what I described above - just an process running arm instructions. If you’re using qemu binfmt_misc runner which uses “user mode emulation” not to be confused with system emulation which does full blown hw emulation. So it’s aready doing similar things to rosetta 2

Yes qemu and Rosetta perform the same basic role here (bintfmt handler for x86 bins), but Rosetta should perform significantly better (otherwise there would be virtually no reason at all to build this).

> Docker Desktop (ie Docker on Mac) absolutely sets up a VM.

Docker runs inside the VM, not the other way around.

Something needs to set up the VM that Docker runs in. Docker Desktop is that something. The GUI even lets you tweak the VM resources. I suppose you could do it all on your own, but most macOS users probably just install Docker Desktop and let it handle the VM.

Docker Desktop has pretty bad performance. Vagrant seems to be the way.

Do you know if these changes will allow Vagrant to configure VMs with Intel operating systems to run on an M1?

Reply on news.ycombinator.com