Most active commenters
  • Syonyk(3)
  • zeusk(3)
  • saagarjha(3)

←back to thread

Why is Apple Rosetta 2 fast? (2022)

(dougallj.wordpress.com)
172 points fanf2 | 12 comments | 19 Nov 24 21:42 UTC | HN request time: 0.239s | source | bottom
Show context
Syonyk ◴[19 Nov 24 22:18 UTC] No.42188705[source]▶
Post got the big one: Total Store Ordering (TSO).

The rest are all techniques in reasonably common use, but unless you have hardware support for x86's strong memory ordering, you cannot get very good x86-on-ARM performance, because it's by no means clear when strong memory ordering matters, and when it doesn't, inspecting existing code - so you have to liberally sprinkle memory barriers around, which really kill performance.

The huge and fast L1I/L1D cache doesn't hurt things either... emulation tends cache-intensive.

replies(6): >>42188819 #>>42189266 #>>42189505 #>>42189556 #>>42189596 #>>42197760 #
jsheard ◴[19 Nov 24 22:35 UTC] No.42188819[source]▶
It's surprising that (AFAIK) Qualcomm didn't implement TSO in the chips they made for the recent-ish Windows ARM machines. If anything they need fast x86 emulation even more than Apple does since Windows has a much longer tail of software support than macOS, there's going to be important Windows apps that stubbornly refuse to support native ARM basically forever.
replies(8): >>42188869 #>>42188881 #>>42188889 #>>42188901 #>>42189055 #>>42189531 #>>42189551 #>>42193997 #
1. scottlamb ◴[19 Nov 24 22:43 UTC] No.42188869[source]▶
Does Windows's translation take advantage of those where they exist? E.g. if I launch an aarch64 Windows VM on my M2, does it use the M2's support for TSO when running x86_64 .exes or does it insert these memory barriers?

If not, it makes sense that Qualcomm didn't bother adding them.

replies(3): >>42188900 #>>42188924 #>>42189541 #
2. Syonyk ◴[19 Nov 24 22:47 UTC] No.42188900[source]▶
I would expect it to not use TSO, because the toggle for it isn't, to the best of my knowledge, a general userspace toggle. It's something the kernel has to toggle, and so a VM may or may not (probably does not) even have access to the SCRs (system control registers) to change it.
replies(2): >>42188929 #>>42189543 #
3. zeusk ◴[19 Nov 24 22:49 UTC] No.42188924[source]▶
The OS can use what hardware supports, Mac OS does because SEG is a tightly integrated group at Apple whereas Microsoft treats hardware vendors at arm's length (pun unintended). There are roadmap sharing, planning events through leadership but it is not as cohesive as it is at Apple.
4. zeusk ◴[19 Nov 24 22:50 UTC] No.42188929[source]▶
TSO toggle on Apple Silicon is a user-space accessible/writable register.

It is used when you install rosetta2 for Linux VMs

https://developer.apple.com/documentation/virtualization/run...

replies(2): >>42188964 #>>42189032 #
5. Syonyk ◴[19 Nov 24 22:56 UTC] No.42188964{3}[source]▶
Are you sure it's userspace accessible?

Based on https://github.com/saagarjha/TSOEnabler/blob/master/TSOEnabl..., it's a field in ACTLR_EL1, which is explicitly (per the ARMv8 spec, at least...) not accessible to userspace (EL0) execution.

There may be some kernel interface to allow userspace to toggle that, but that's not the same as being a userspace-accessible SCR (and I also wouldn't expect it to be passed through to a VM - you'd likely need a hypercall to toggle it, unless the hypervisor emulated that, though admittedly I'm not quite as deep weeds on ARMv8 virtualization as I would prefer at the moment.

replies(1): >>42189003 #
6. zeusk ◴[19 Nov 24 23:03 UTC] No.42189003{4}[source]▶
Hmm, you’re right - maybe my memory serves incorrectly but yeah it seems it is privileged access but the interface is open to all processes to toggle the bit.
7. shadowfacts ◴[19 Nov 24 23:07 UTC] No.42189032{3}[source]▶
It is not directly accessible from user-space. Making it so requires kernel support. Apple published a set of patches for doing this on Linux: https://developer.apple.com/documentation/virtualization/acc...

Without that kernel support, all processes in the VM (not just Rosetta-translated ones) are opted-in to TSO:

> Without selective enablement, the system opts all processes into this memory mode [TSO], which degrades performance for native ARM processes that don’t need it.

replies(1): >>42189575 #
8. saagarjha ◴[20 Nov 24 00:20 UTC] No.42189541[source]▶
No because Windows is not aware of how Apple does it. There exist Linux patches documenting how to do so, though.
replies(1): >>42190069 #
9. saagarjha ◴[20 Nov 24 00:21 UTC] No.42189543[source]▶
This is exposed to guest kernels of Sequoia (and maybe earlier?).
10. mrpippy ◴[20 Nov 24 00:26 UTC] No.42189575{4}[source]▶
Before Sequoia, a Linux VM using Rosetta would have TSO enabled all the time.

With Sequoia, TSO is not enabled for Linux VMs, and that kernel patch (posted in the last few weeks) is required for Rosetta to be able to enable TSO for itself. If the kernel patch isn't present, Rosetta has a non-TSO fallback mode.

11. scottlamb ◴[20 Nov 24 01:45 UTC] No.42190069[source]▶
The article says the following:

> As far as I know this is not part of the ARM standard, but it also isn’t Apple specific: Nvidia Denver/Carmel and Fujitsu A64fx are other 64-bit ARM processors that also implement TSO (thanks to marcan for these details).

I'm not sure how to interpret that—do these other parameters have distinct/proprietary TSO extensions? Are they referring to a single published (optional) extension that all three implement? The linked tweet has been deleted so no clues there, and I stopped digging.

replies(1): >>42190273 #
12. saagarjha ◴[20 Nov 24 02:22 UTC] No.42190273{3}[source]▶
Those are just TSO all the time I think. So they are stronger than the ARM requirement