系统与基础设施dougallj.wordpress.com编辑精选
Rosetta 2 为什么这么快？
Why is Rosetta 2 fast?
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博客从实现层面分析苹果 Rosetta 2 为什么性能出色：它如何把 x86-64 代码翻译成 Apple Silicon 的 ARM64 代码，并在翻译质量、启动开销与运行时处理之间做取舍。作者用具体指令和翻译策略说明其优化思路。
为什么经久不衰：它把复杂的二进制翻译工程拆解得具体清楚，揭示了 Rosetta 2 性能背后的务实设计，对理解翻译层、模拟器和苹果架构迁移仍有长期价值。
HN 评论精选
称赞文章，并对比 68K→PowerPC 模拟器：Rosetta 2 同样以务实、启动快和性能可预测取胜。
这篇写得太好了。多巧妙的设计！我记得苹果在 68K 到 PowerPC 迁移时有一个完全不同但同样巧妙的方案。68K 的指令字是 16 位，通常还带一些 16 位参数。模拟器的核心循环会读取下一条指令，然后直接跳进一大块 64K×8 字节的 PPC 代码里。于是每条 68K 指令都有两条专用的 PPC 指令：通常一条用来设置寄存器，另一条跳转到公共代码。那个方案和 Rosetta 2 的共同点是极其务实——启动快，在大多数负载下性能相当稳定可预测，即使理论峰值速度远低于最先进的 JIT。有人知道 PPC 到 x86 的翻译是怎么实现的吗？
iainmerrick查看英文原文
This is a great writeup. What a clever design! I remember Apple had a totally different but equally clever solution back in the days of the 68K-to-PowerPC migration. The 68K had 16-bit instruction words, usually with some 16-bit arguments. The emulator’s core loop would read the next instruction and branch directly into a big block of 64K x 8 bytes of PPC code. So each 68K instruction got 2 dedicated PPC instructions, typically one to set up a register and one to branch to common code. What that solution and Rosetta 2 have in common is that they’re super pragmatic - fast to start up, with fairly regular and predictable performance across most workloads, even if the theoretical peak speed is much lower than a cutting-edge JIT. Anyone know how they implemented PPC-to-x86 translation?
用 HP 的二进制转译器 A→A 优化案例说明 JIT/转译可超越原生代码，并期待编译器提供快速与慢速优化模式。
多年前 Java 相关研究盛行时，HP 需要在新硬件上跑不完全向后兼容的旧二进制，于是做了二进制转译器（可能还是 JIT）。有趣的是他们做了 A→A 模式：输入和输出同一架构的机器码，输出反而更快，说明原生代码用 JIT 技术仍有改进空间。我一直希望编译器能有用于开发测试的快速模式和用于正式构建的慢速增量模式；也喜欢让在意某件事的人自己承担代价，而不是转嫁他人。让 CI 机器整天啃难题来榨取最后 10% 性能，在 16 核消费级硬件时代是个好用例，缓存上次运行的提示也是好事。
hinkley查看英文原文
I remember years ago when Java adjacent research was all the rage, HP had a problem that was “Rosetta lite” if you will. They had a need to run old binaries on new hardware that wasn’t exactly backward compatible. They made a transpiler that worked on binaries. It might have even been a JIT but that part of the memory is fuzzy. What made it interesting here was that as a sanity check they made an A->A mode where they took in one architecture and spit out machine code for the same architecture. The output was faster than the input. Meaning that even native code has some room for improvement with JIT technology. I have been wishing for years that we were in a better place with regard to compilers and NP complete problems where the compilers had a fast mode for code-build-test cycles and a very slow incremental mode for official builds. I recall someone telling me the only thing they liked about the Rational IDE (C and C++?) was that it cached precompiled headers, one of the Amdahl’s Law areas for compilers. If you changed a header, you paid the recompilation cost and everyone else got a copy. I love whenever the person that cares about something gets to pay the consequence instead of externalizing it on others. And having some CI machines or CPUs that just sit around chewing on Hard Problems all day for that last 10% seems to be to be a really good use case in a world that’s seeing 16 core consumer hardware. Also caching hints from previous runs is a good thing.
提供无需 root/关闭 SIP 提取 Rosetta AOT 二进制的方法和工具。
要查看提前翻译（AOT）后的 Rosetta 代码，我记得当时得禁用 SIP、编译一个新的 x86 二进制、给它一个唯一名字、运行它，然后运行 otool -tv /var/db/oah///unique-name.aot（或用你喜欢的工具——它只是一个 Mach-O 二进制）。这是旧版 macOS 上的做法，现在可能已经变了、改进了。我的 aotool 项目用了一个技巧，无需 root 或禁用 SIP 就能提取 AOT 二进制：https://github.com/lunixbochs/meta/tree/master/utils/aotool
lunixbochs查看英文原文
> To see ahead-of-time translated Rosetta code, I believe I had to disable SIP, compile a new x86 binary, give it a unique name, run it, and then run otool -tv /var/db/oah///unique-name.aot (or use your tool of choice – it’s just a Mach-O binary). This was done on old version of macOS, so things may have changed and improved since then. My aotool project uses a trick to extract the AOT binary without root or disabling SIP: https://github.com/lunixbochs/meta/tree/master/utils/aotool
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选