M1 上的其他 x86-64 模拟器是否可以利用 Rosetta 2 使用的相同优化？
Is it possible for other x86-64 emulators on M1 to leverage the same optimizations used by Rosetta 2?
我很好奇 运行ning x86-64 二进制文件在 Apple M1 平台上使用 Rosetta 2 与仿真的性能特征有很大不同，例如 Docker Desktop 当前使用 QEMU.
我明白为什么仿真这么慢，但是关于 Rosetta 2 为什么这么快的解释在这个 Twitter 帖子中有详细解释：https://twitter.com/ErrataRob/status/1331735383193903104
该解释的要点是，在通常情况下，arm 和 x86 具有相反（且不兼容）的内存寻址方案，这需要大量的仿真开销，但 M1 芯片通过允许其访问内存的硬件优化解决了这个问题使用这两种寻址方案。实际上，当 Rosetta 2 仿真指令被 运行 设置时，会设置一个标志让处理器知道使用 x86 样式的寻址方案。
假设这个解释是合理的（如果有人比上面的 Twitter 线程有更好的来源报告，我会很感激在评论中包含），这种优化可以用于完整的硬件仿真在技术上是否合理，例如 运行ning x86-64 Linux Docker 容器，或 运行ning 一个完整的 x86-64 Windows 桌面虚拟机 a la VMware Fusion/VirtualBox？或者，在这些场景中，单独的操作系统层是否会妨碍利用内存排序优化？
另外，此处理器模式（标志或指令）是否已记录并发布供第 3 方使用，还是仅供 Apple 私有？
不是内存寻址，内存排序。即对于用于线程间同步的无锁原子 - 在 x86 中，每个 asm load/store 分别是 acquire/release。 （使用真正的 x86 CPUs 进行推测性早期加载，因此当单个线程在其他线程未写入的内存上运行时，性能在正常情况下不会受到影响。）
M1 具有对此类模式的硬件支持，以及对 运行 原生 AArch64 代码最有效的弱排序模式。参见
- https://singhkays.com/blog/apple-silicon-m1-black-magic/#performance-must-suck-when-trying-to-emulate-x86-on-arm-right
- https://www.reddit.com/r/hardware/comments/i0mido/apple_silicon_has_a_runtime_toggle_for_tso_to/.
是的，https://github.com/saagarjha/TSOEnabler 是用于切换该支持的开源软件。但它是一个内核扩展，代码签名让 MacOS 允许它变得棘手，你必须对其进行签名或禁用签名验证或其他东西：
Supposedly, you should be able to use this if you build and sign the kernel extension (disabling SIP if you aren't using a KEXT signing certificate) and drag it into /Library/Extensions. A dialog should come up to prompt you to enable the extension in the Security & Privacy preferences pane, you allow it from there and restart, and it will be installed. (If you're not seeing it, the permissions on the extension might be wrong: try a chown -R root:wheel.) In practice this can go wrong in many ways, and I have had luck by "resetting everything" and trying to install after doing the following:
[...] see the link for the list of steps
所以，是的，QEMU 的 x86 仿真器可以使用与 Rosetta-2 的 x86 仿真器相同的硬件支持是合理的。它们都是 x86 仿真器。
如您所说，主要问题是 Apple 提供 public API 以启用硬件模式，因此人们不必手动安装此内核模块；我相信大多数人都不想这样做。我不太了解软件情况，我更感兴趣的是CPU-架构细节。
我很好奇 运行ning x86-64 二进制文件在 Apple M1 平台上使用 Rosetta 2 与仿真的性能特征有很大不同，例如 Docker Desktop 当前使用 QEMU.
我明白为什么仿真这么慢，但是关于 Rosetta 2 为什么这么快的解释在这个 Twitter 帖子中有详细解释：https://twitter.com/ErrataRob/status/1331735383193903104
该解释的要点是，在通常情况下，arm 和 x86 具有相反（且不兼容）的内存寻址方案，这需要大量的仿真开销，但 M1 芯片通过允许其访问内存的硬件优化解决了这个问题使用这两种寻址方案。实际上，当 Rosetta 2 仿真指令被 运行 设置时，会设置一个标志让处理器知道使用 x86 样式的寻址方案。
假设这个解释是合理的（如果有人比上面的 Twitter 线程有更好的来源报告，我会很感激在评论中包含），这种优化可以用于完整的硬件仿真在技术上是否合理，例如 运行ning x86-64 Linux Docker 容器，或 运行ning 一个完整的 x86-64 Windows 桌面虚拟机 a la VMware Fusion/VirtualBox？或者，在这些场景中，单独的操作系统层是否会妨碍利用内存排序优化？
另外，此处理器模式（标志或指令）是否已记录并发布供第 3 方使用，还是仅供 Apple 私有？
不是内存寻址，内存排序。即对于用于线程间同步的无锁原子 - 在 x86 中，每个 asm load/store 分别是 acquire/release。 （使用真正的 x86 CPUs 进行推测性早期加载，因此当单个线程在其他线程未写入的内存上运行时，性能在正常情况下不会受到影响。）
M1 具有对此类模式的硬件支持，以及对 运行 原生 AArch64 代码最有效的弱排序模式。参见
- https://singhkays.com/blog/apple-silicon-m1-black-magic/#performance-must-suck-when-trying-to-emulate-x86-on-arm-right
- https://www.reddit.com/r/hardware/comments/i0mido/apple_silicon_has_a_runtime_toggle_for_tso_to/.
是的，https://github.com/saagarjha/TSOEnabler 是用于切换该支持的开源软件。但它是一个内核扩展，代码签名让 MacOS 允许它变得棘手，你必须对其进行签名或禁用签名验证或其他东西：
Supposedly, you should be able to use this if you build and sign the kernel extension (disabling SIP if you aren't using a KEXT signing certificate) and drag it into /Library/Extensions. A dialog should come up to prompt you to enable the extension in the Security & Privacy preferences pane, you allow it from there and restart, and it will be installed. (If you're not seeing it, the permissions on the extension might be wrong: try a chown -R root:wheel.) In practice this can go wrong in many ways, and I have had luck by "resetting everything" and trying to install after doing the following:
[...] see the link for the list of steps
所以，是的，QEMU 的 x86 仿真器可以使用与 Rosetta-2 的 x86 仿真器相同的硬件支持是合理的。它们都是 x86 仿真器。
如您所说，主要问题是 Apple 提供 public API 以启用硬件模式，因此人们不必手动安装此内核模块；我相信大多数人都不想这样做。我不太了解软件情况，我更感兴趣的是CPU-架构细节。