[jillesvangurp]

X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.

[Wowfunhappy]

Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.

[ogre_codes]

This whole territory is pretty much unknown right now. Whether we can have reasonably performant x86 containers is up in the air.

[musicale]

Yes, it's definitely "performant" if by "performant" you mean "exactly matching the well-established performance of qemu emulation" which means: slower than Rosetta2 with higher CPU/memory/power usage but still functionally correct for the most part.

If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

[skissane]

> If by "performant" you mean "as fast as it used to run on x86 Mac hardware" than the answer is: No, it's emulation, and it's slower than Rosetta2.

I wonder if this would motivate someone to build an x64-to-ARM translation layer for Linux which is closer to Rosetta2 than qemu-user-static in performance?

One of the secrets of Rosetta2's performance is Apple Silicon processor extension enabling ARM code to use the x86 memory model. There is no reason in principle why some x64-to-ARM translator running on Linux on Apple Silicon could not exploit the same processor extension.

Another secret is that it predominantly does AOT translation, and only uses interpretation/JIT for x64 code generated dynamically (such as by an x64 JIT). There is no reason in principle why something on Linux couldn't do the same thing.

Perfect world scenario, Apple would open source Rosetta2 and it would be ported to Linux. Apple probably won't do that because they've invested a lot of money into it and it gives them a competitive advantage over other ARM-based platforms (such as Microsoft Surface Pro X). (I do hope I'm wrong about this though.)

[ant6n]

I’d say the reason qemu is slow isn’t aot vs jit, but that qemu is very generic allowing translation between all sorts of different architectures. It uses an intermediate representation where you lose those possible 1-to-1 mappings between x86 und arm.

I was fiddling for a while on x86 emu for arm, it’s definitely possible to be faster than qemu, but it’s a very big project and unclear whether somebody will just do it in their free time.

[coldtea]

>but still functionally correct for the most part.

Why, would any part be fuctionally incorrect under qemu?

I mean, aside for web and app development, not for writing hardware drivers...

[Wowfunhappy]

I'd expect it to be exactly as performant as qemu's x86 emulation always is. The M1 is new, but qemu is not.

[fomine3]

So it means plain old binary translation without hardware assist. I wonder that whether QEMU's binary translation is not optimized well nowadays because no one uses it for production (we use with VT-x/EPT or AMD equivalent).

[ogre_codes]

I think QEMU is hardware emulation, not translation.

[fomine3]

Qemu provides both device emulation, and x86 emulation by binary translation. Use qemu-kvm to accelerate x86 emulation by hardware assist.

[ant6n]

I have been running x86 containers inside a chromebook for years. Never had a an issue, it’s just a bit slow.