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.
If you are not familiar, Rosetta is how Apple Silicon Macs run existing Mac x86 binaries and it is highly performant. It does binary pre-compilation and cacheing. It also works with JIT systems. They are now making that available within Linux VMs running on Macs.
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.
This might be an unpopular opinion, but I really think people should ignore bench scores and run the processes they need themselves. See what it feels like, and how comfortable you are with that.
Benchmarks are good for bragging rights and maybe convincing over-zealous accounting to approve a purchase (but even then that’s probably not all there is to it.)
All the telling similes I can briefly think of, from "in Chad drinking water availability does not reach 40% and in Namibia exceeds 80% - but see what it feels like, and how comfortable you are with that" or "near that peaks the temperature is 10°C, and in the valley 20°C - but see what it feels like, and how comfortable you are with that", seem to be part a much more sophisticated reality (the "ceteris paribus" constraint is less foreseeable) than that of "on that machine this defined code runs in half the time of that one" - especially when you are trying to get an idea of the world, not to see how you will feel like and how comfortable you are with that.
You can decide beforehand if increased speed with respect to your experience on your machines is beneficial to you or not.
> […] I really think people should ignore bench scores and run the processes they need themselves. See what it feels like, and how comfortable you are with that.
And how do people without disposable income judge?
I have benchmarked x86 on ARM Linux VM with Rosetta, and while Geekbench 5 shows similar performance between ARM and x86 version (for both single and multi core), this does not translate to the actual real world use cases.
When benchmarking x86 and ARM containers, our application seems to be around ~5x slower with x86-rosetta, and similarly can be observed for mysql-server or just doing `apt install`.
This is still significantly better than using qemu emulation, but it's not really usable in our case.
I've also encountered segmentation faults when running x86 `npm` inside Docker, so couldn't even install packages, but didn't dig further as to what's the cause.
(Note: I've created a simple macOS app using Virtualization framework, enabled Rosetta, and loaded Ubuntu Focal. I've installed the latest version of Docker, which automatically used `rosetta` when encountering x86 executables. Maybe this setup is not ideal.)
> It does binary pre-compilation and cacheing. It also works with JIT systems.
Much more impressively it also leverages a custom hardware x86-like memory model unique to the M1/Apple ARM chips. That's where most of the performance really comes from, as I understand it.
https://developer.apple.com/documentation/virtualization/run...
https://developers.apple.com/videos/play/wwdc2022/10002/
If you are not familiar, Rosetta is how Apple Silicon Macs run existing Mac x86 binaries and it is highly performant. It does binary pre-compilation and cacheing. It also works with JIT systems. They are now making that available within Linux VMs running on Macs.