Live data from Hacker News

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

news.ycombinator.com

51–60 of 284 posts

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

#51

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.…

My understanding is the AOT won’t be available to Linux; it’s JIT only.

The WWDC video is unclear but seems to imply that it works the exact same as on macOS.

Hopefully, this is the right timestamp:

https://developer.apple.com/videos/play/wwdc2022/10002/?time...

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

#52
You say your job is DevOps work so you probably feel the pain more than most people do.

Not being able to run amd64 containers hit me hard. I fought it until I just gave in and made sure that everything we built could be built under amd64 or arm64. For specific builds on a specific architecture, GitHub action runner on a cloud box. (Or pick your flavor of CI/CD).

Once I looked past my machine into an ecosystem and embraced the arm as just another build artifact it was easier.

I also reject testing locally as a measure of working software. So that eliminates some pain. If your coverage is high then this is an easy shift. Have a dev environment that you can test that matches your assumed architecture, toolchain wise.

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

#53
I’m working on re-factoring a developer environment from using vagrant/virtualbox and docker to only docker.

The prior goal was to mock production as closely as possible.

The realization is that macos as a host machine for orchestration is close enough to build. More strict validation can be done in CI and a staging env.

So for this project, the forced transition away from virtualbox Has actually led to simplification and asking questions about why it was “required” previously.

It is a bit of a pain only because some team members will need more support than others so the entire setup kind of needs to be clean and carefully documented when there is other stuff to do.

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

#54
No problems here. Node, php, apache, mariadb, postgresql run native out of the box via homebrew. Java11 and Java17 have native aarch64 builds via homebrew and/or temurin (or the oracle openjdk project, which unfortunately doesn't seem to care about being a responsible security patch vendor at all). Android studio is fine except they don't support androidtv emulators yet. UTM with an aarch64 debian host runs mssql (azure edge sql) in docker natively, as well as anything you'd expect from a high quality debian distribution. UTM with windows 11 arm64 even runs vs2022 through its fairly efficient x64 usermode translator (WPF apps and everything). Xcode and the iOS simulator works great as expected, too.

Even the x64 java8 SDK for macOS runs without a glitch, I mean how impressive is that, with JIT and everything? Mind blown.

I didn't even understand the point of the new macOS 13 ventura linux rosetta thing until I realized some people are still running x64 docker containers. (why, though?)

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

#55
Higher Education IT here. For our users that we support, it's been great on the whole... except for those who need to use a VM for the occasional Windows-only desktop app. UTM[1] seems to be the best option (everything else is in technical preview or not supported?) but it's slow as a dog to emulate x86. ARM Windows isn't great either if you want to just virtualize. Suggestions welcome!

1. https://getutm.app/

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

#56

I do most of my work in Go (with the very occasional splash of Swift or Kotlin) and the move to M1 has been utterly seamless for me. So much so that I often forget I'm working on an ARM64 machine until I forget to set GOARCH when compiling and then try to copy a binary to a remote machine. The majority of Docker images that I use are available for ARM and the few that aren't perform fine under Docker for Mac emulatio…

It seems like if someones workflow is heavily local container based, then the m1 has been a rough transition. Otherwise it's been pretty seamless.

I'm on my second m1 machine (m1 mba, now m1 max mbp), and I only had a few issues early on with terraform. My day to day software dev is web, go, and java.

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

#58

Earlier quoted context omitted.

My understanding is the AOT won’t be available to Linux; it’s JIT only.

Interesting. Where did you see that? I'm still trying to get a handle on the latest changes.

Says so here, which was posted earlier this week. I cannot verify it’s accuracy. I do work for Apple but not at all on related stuff.

https://threedots.ovh/blog/2022/06/quick-look-at-rosetta-on-...

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

#59
post #33

I'm in a similar boat - love the performance/battery of my M1 MacBook Air, but the ecosystem is just too messy at the moment for me. I have a few tools I need to use that haven't yet been making official Apple Silicon releases due to GitHub actions not supporting Apple Silicon fully yet. The workaround involves maintaining two versions of homebrew, one for ARM and one for x86-64, and then being super careful to make…

> It is interesting how much impact GitHub has had by not having Apple Silicon support

Putting on my tin-foil hat for a sec: GitHub is owned by Microsoft, who would really stand to benefit from slowing down Apple Silicon adoption a bit...

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

#60

On the whole it's been good. I work on scientific software, so the biggest technical issue I face day-to-day is that OpenMP based threading seems almost fundamentally incompatible with M1. https://developer.apple.com/forums/thread/674456 The summary of the issue is that OpenMP threaded code typically assumes that a) processors are symmetric and b) there isn't a penalty for threads yielding. On M1 / macOS, what happen…

Can you not do this using the CPU affinity environment variables and just ignoring the efficiency codes? I was under the impression you could bind to specific cores with:

GOMP_CPU_AFFINITY=“1 2 5 6”

With thread 1 bound to core 1, thread 2 on core 2, thread 3 on core 5, thread 4 on core 6. I don’t have an M1 to play around on but I’d have assumed that the cores are fixed IDs.

Aside from that, if the workload is predictable in time, using a more complex scheduling pattern might help. You could perhaps look at how METIS partitions the workload, but see if it’s modifiable by adding weights to the cores reflective of their relative performance. Generally, to get good OMP performance I always found it better to treat it almost like it’s not shared memory, because on HPC clusters, you have NUMA anyway which drags performance down once you have more threads than a single processor has cores in the machine

Post reply on HN