Live data from Hacker News

Ask HN: How are you dealing with the M1/ARM migration?

news.ycombinator.com

61–70 of 284 posts

Re: Ask HN: How are you dealing with the M1/ARM migration?

#64
post #48

At least some aspects of this issue are getting better as we speak. The latest Mac OS (in beta) supports virtualizing ARM Linux but also enables the ARM Linux system to use Apple's speedy Rosetta 2 x86 binary compiler and JIT compiler to run x86 programs within the ARM Linux VM. Based on descriptions, it seems that the rest of the hypervisor VM framework has also matured substantially this release. https://developer.…

> highly performant Last thing I read, 70% of the native performance was shown by running GeekBench through Rosetta (with a few odd results noted). If somebody has better info... Edit: I see that Nov 2020 checks returned an 80% performance, and there was discussion on HN at (at least) https://news.ycombinator.com/item?id=25105597

Here are my numbers for the original M1 (not Pro or Max) soon after release:

ARM Geekbench single core on M1 MacOS is 1734. ARM Geekbench single core on WinARM in VM on M1 is 1550. x86 single core on i9 MB Pro MacOS is 1138. x86 in emulation on M1 MacOS is 1254.

Yes, 72% x86 Rosetta vs. M1 Native. However, x86 Rosetta on M1 was faster than the previous i9 2019 Macbook Pro x86 native. I consider that to be performant for running code that was compiled for a very different architecture.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#65
post #40

1. Run arm-based debian using Parallels, headless using `prlctl`. SSH in and use tmux. 2. Everything you install will be arm based. Docker will pull arm-based images locally. Most every project (that we use) now has arm support via docker manifests. 3. Use binfmt to cross-compile x86 images within prlctl, or have CI auto-build images on x86 machines. That pretty much does it.

Yup. We have a lot of complex dependencies so a couple of us got M1s so we could charge into it headfirst to get it sorted. It wasn’t too bad. We had a couple of 3rd party things stuck on x86 so we emulated them on qemu within the vm. Slow, but ok (eventually we replaced them).

We were using UTM but have recently switched to Parallels, which is nice.

Our prod stayed on x86 but we’ve started moving to graviton3 which is better bang for buck. Suspect it’ll end up being a common story for others too.

m1s are just such nice machines that I’d go quite out of my way to stay on them now.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#66
I just added creating and publishing ARM64 docker containers to our automated release process and the CI (GitHub Actions) time went from about 10 minutes to an hour and half.

I don't expect many teams to volunteer to suffer this sort of slowdown and complexity in the near term.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#68
I'm happy with it.

Here's a tip for anyone with docker compatibility problems: If you add `platform: "linux/amd64"` to your docker-compose (there's also a similar command for Dockerfile iirc), it just gets the x64 images and emulates those.

There is emulation overhead of course, but it's not perceivable in my experience, compared to running native images.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#70
I did buy MacBook M1.

Installed Asahi Linux, it made possible to keep OS running all the time, keep HexChat IRC running, and not shutdown when away from keyboard like on macOS.

But that M1 did only last 4 days. Then it did not boot anymore. So I returned it to warranty repair, and canceled buying it.

Post reply on HN