Live data from Hacker News

LXD containers on macOS at near-native speeds

beringresearch.github.io

41–50 of 134 posts

Re: LXD containers on macOS at near-native speeds

#41
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

Have you tried enabling Virtiofs in Docker Desktop? On my M1 Mac that sorted the performance for me for large PHP apps, and I haven't experienced the permissions problems that some people have (there is a test build that appears to fix those out now).

Re: LXD containers on macOS at near-native speeds

#42

Earlier quoted context omitted.

Wait, what? QEMU can pass x86 instructions directly to Rosetta without emulating an entire host OS?

No, QEMU runs an ARM VM. Inside that VM, Rosetta for Linux can be used to run x86 executables, just like on macOS.

so arm macbooks are still problematic for developers who use containers and x86 servers...

it's still surprising to me that they did this as i always got the sense that developer word of mouth helped drive a lot of macbook adoption in the 2000s.

Re: LXD containers on macOS at near-native speeds

#43
post #2

This is good news. I come from the development background and the number one use case of containers on macOS is development enviroments, as on Windows too. For this use case, file system IO has always been bottleneck, not CPU. I do not know if there is some silver bullet in the horizon that could make this faster.

virtiofs is supported by newer Docker builds. It used to be very buggy with permissions, but the latest builds should have solved that.

I am personally slowly moving back to Docker after having used limactl for a long time. It's just a pain in the ass.

A Linux laptop is better for all intents and purposes, except the shitty battery life...

Re: LXD containers on macOS at near-native speeds

#44

Does QEMU emulate the CPU on macOS?

The CPU architecture of the VM and Host have to match, otherwise you get software emulation which is very very slow. It's good enough for occasional usage, but nowhere near good enough for daily development purposes.

Re: LXD containers on macOS at near-native speeds

#45
post #29

Earlier quoted context omitted.

Not if you’re running x86 emulation on an ARM host. It’s terribly slow. EDIT: This is from experience. When I started using a M1 mac, our docker builds on x86 images took up to 5x or 10x longer vs running on an arm64 image. Had slightly faster, but similar results running my own docker host on Lima, or podman, or building without docker inside a UTM host which also uses qemu.

No, it's decent performance. Minimum 25% of native, and even more using Rosetta: https://news.ycombinator.com/item?id=32149080

For real world use cases like making cross-platform builds, 1/4 of native speed is pretty far from decent.

Re: LXD containers on macOS at near-native speeds

#46
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

Canonical has a product of their own: https://multipass.run/

They all use the underlying OS hypervisor so I’m not sure you can get perceivable performance out of one solution over the other.

Re: LXD containers on macOS at near-native speeds

#47
post #32
post #10

Earlier quoted context omitted.

lxd is so much easier than alternatives like systemd-nspawn. 3 minutes search reveals an easy to follow tutorial. https://ubuntu.com/server/docs/containers-lxd

Thanks but I wasn't talking about lxd, but about the underlying technology.

[deleted]

Re: LXD containers on macOS at near-native speeds

#48

Earlier quoted context omitted.

Depends. QEMU can use Apple's Hypervisor virtualization framework to run ARM64 operating systems on Apple Silicon without emulation. It seems to be possible to then use Rosetta 2 to run x64-code on those operating systems.

Can confirm this works, but some applications will be slow. Seen a magnitude of difference with x86 JVM containers between Rosetta 2 and native ARM64.

Rosetta 2 works great for AoT stuff but for JIT you'll always end up with at least a 2x slowdown since it needs to always JIT the JVMs JIT output. That said, it working at all is pretty amazing.

Re: LXD containers on macOS at near-native speeds

#49
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

We're using Multipass + Bravetools (https://github.com/bravetools/bravetools) / Docker to build system/application containers.

I believe multipass uses SSHFS (https://discourse.ubuntu.com/t/how-to-improve-mounts-perform...) to mount filesystems between the host and the VM. Performance has been excellent.

Re: LXD containers on macOS at near-native speeds

#50
post #40

So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”. I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

Because docker for Mac has always kind of sucked, I’ve moved on to making nix-based development environments and I’ve been very pleased so far.

Lately I’ve been trying https://devenv.sh/ and it works great!

I haven’t tried it for ruby, though I have used vanilla nix shell for ruby projects before and it worked quite well after I over-rode GEM_PATH and GEM_HOME to the correct values.

Post reply on HN