借助 AI，5 微秒完成 JIT 编译
JIT Compiling Code in 5μs
过去，编写快速 JIT 编译器是只有汇编高手才能掌握的“黑魔法”，导致没有生产级数据库能自研 JIT，只能依赖 LLVM 或生成 C/C++ 代码，编译耗时严重。在构建 pgrust 时，我原本以为实现 JIT 难如登天，但在 AI 的辅助下，直接生成汇编代码变得异常简单。最终，pgrust 的 JIT 编译器将编译时间压缩至约 5 微秒，让我们能够 JIT 编译每一条 SQL 查询，而不仅仅是子集。本文将通过构建一个简单的正则表达式引擎，带你一步步拆解如何利用 copy-and-patch 技术和汇编模板，打造媲美手写代码性能的 JIT 编译器。
历史上，快速 JIT 编译一直是一项黑魔法，要写出高效的 JIT 编译器，你必须懂得如何编写汇编代码。
HN 评论区
104- MaxBarraclough
让我想起 2024 年那篇博客《看啊，我给 PostgreSQL 写了一个新的 JIT 编译器》[0]。两篇文章都感叹 Postgres 基于 LLVM 的 JIT [1] 生成代码太慢。
> JIT 编译器的稀缺性让我相信，历史上实现 JIT 编译器太难了，以至于不值得去做。
这仅适用于从头手写一个 JIT。JIT 其实并不稀缺，只是大家常用 LLVM（及其他框架）。每个主流解释器都有 JIT 编译器。PCRE2 就有 JIT 编译器。市面上还有比 LLVM 代码生成更快的 JIT 框架：Cranelift、GNU Lightning、Mir。我怀疑它们可能无法比定制的“复制 - 修补”（copy-and-patch）JIT 更快，但肯定比 LLVM 快得多。
[0] https://www.pinaraf.info/2024/03/look-ma-i-wrote-a-new-jit-c... , 讨论：https://news.ycombinator.com/item?id=39742916
- agnishom
我推荐 Russ Cox 关于实现正则表达式引擎的文章：https://swtch.com/~rsc/regexp/
非常相关。
- catlifeonmars
这或许有点元（meta），但这篇读起来很愉快。读到一篇关于使用 LLM 的文章，却没有那种“也是由 LLM 写的”味道，真是让人耳目一新。
我可能会用这种方法来生成我正在实验的 JIT 防火墙的模板（stencils）。
我还想到，这也可以用来实时生成 eBPF 字节码。
- glum64
呃，Common Lisp，那里的 JIT 不仅可用，而且可控：程序员可以决定哪些值得编译，哪些不值得。
除了运行时，JIT 在代码编译或加载执行时也可用（也就是说，你是在考虑编译速度还是加载速度的提升吗？没问题，你可以把这个提速逻辑本身也编译成本地机器码，如此无限递归……）。
- mgaunard
这种方法的缺点是它并不是真正的 JIT 编译，只是带有基本替换的汇编模板。
因为没用 LLVM，你就错过了它提供的所有优化。
- malisper
我是作者。如果你对这篇文章或 pgrust 有任何疑问，请告诉我。
- glenjamin
pgrust 听起来很有趣，但鉴于改动如此深入，似乎没有可行的路径将其合并到上游（upstream）——最终目标是让它足够稳健从而获得广泛采用吗？
- hamilyon2
它使用复制 - 修补（copy-and-patch）编译技术来实现这一点。