Prism 二进制翻译：性能代价几何？
On Binary Translation and Its Consequences
PC 市场对 CPU 设计者而言是块硬骨头，尤其是软件兼容性。Microsoft 的 Prism 二进制翻译器试图让 x86-64 应用在 aarch64 架构上无缝运行，但这并非没有代价。我使用 Geekbench 7 对 Snapdragon X2 Elite、Neoverse N1 和 N2 等核心进行了深度测试。数据显示，二进制翻译会导致指令量翻倍，带来显著的性能惩罚，即便是 Snapdragon 的高频宽核心也难以完全抵消这一损失。不同工作负载受影响程度差异巨大，尤其是依赖 AVX 指令的视频处理任务。虽然 Prism 针对 Qualcomm 核心做了优化，但架构本身的特性，如乱序执行能力和缓存延迟，才是决定最终体验的关键。
二进制翻译会带来性能惩罚，这一点毋庸置疑，因为 x86-64 指令有时无法直接映射为 aarch64 指令。
HN 评论区
17- cwzwarich
[免责声明：我是 Rosetta 2 的作者，所以我说的每句话都带有偏见。]
当代的乱序执行 CPU 功能严重过剩；微架构师们为了在某个基准测试上多挤出 0.1% 的性能提升，就会为引入新特性找理由。最终结果就是，CPU 处理二进制翻译器带来的代码膨胀时表现相当不错。
在二进制翻译器中添加更多优化也存在巨大的权衡。你希望既能精确处理异常（尤其是由非法内存访问引起的异常），又能向用户态异常处理器呈现源程序架构上有效的状态。有些优化在原则上很容易实现，但为了维护源程序状态与翻译后程序状态之间的映射却非常棘手。这种复杂性负担，加上调试新增复杂性（或预先进行详尽验证）的难度，塑造了你在编写生产级二进制翻译器时的许多决策。你脑子里应该永远有比实际用得着的更多“酷炫”想法。
- torginus
当我购买 M1 MacBook 时，我亲身体验了二进制翻译效果有多好。它几乎完美，只有一个巨大的例外——任何使用 JIT（即时编译）的东西，比如 Electron 应用或 Java 软件（基于 IntelliJ 的 IDE）。这有点讽刺——JIT 的设计初衷是为了实现跨 CPU 架构的便携性，但它们通常却是最难移植的代码部分，而且它们让这种二进制翻译方法（编译时间相对较长但执行时间较好）变得非常缓慢且痛苦。
- functionmouse
> PC 领域的消费者期望在各种应用中都能获得高性能
硬件设计师认为用户想要什么，与用户实际要求的什么之间，似乎一直存在裂痕，直到最近主要 OEM 厂商推出如 MacBook Neo 这样的产品才开始解决。
我认识的人里没人想要更快的 CPU；他们想要的是称职、更快、原生体验的软件，以及更节能的硬件。至少过去十年来，CPU 的速度对于大多数用户甚至游戏玩家所做的事情来说已经绰绰有余了。我正用 RTX 2080 和 i7-4790k（一款 2013 年的 CPU，连基础版 M1 都能轻松超越）玩那款新出的、以 demanding 著称的《乐高蝙蝠侠》游戏，游戏运行得很流畅。我有信心，大多数人并不需要比 M1 更好的性能。