编程语言与软件工程2025arxiv.org
尝试赶上 JIT 编译器
An Attempt to Catch Up with JIT Compilers
进阶 · 约 30 分钟读完前置知识：编译器基础、JIT 编译、内联缓存
导读
这篇论文记录了一次尝试追赶 JIT 编译器性能的实验，核心围绕内联缓存（inline cache）等动态语言优化技术展开，最终结果并不理想。作者以负面结果（negative results）的形式发表，说明仅靠内联缓存等微优化难以缩小与成熟 JIT（如 HotSpot、V8）的差距。
HN 关注点：HN 读者长期关注 JIT 编译器这一经典话题，这篇负面结果论文引发了关于 JIT 承诺是否兑现、内联缓存真正价值以及研究方法论的讨论。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 1
质疑质疑 JIT 三十年来从未真正兑现性能承诺，手工优化的 AoT 仍是性能标杆
这篇论文似乎缺乏扎实的依据。事实上，Java HotSpot 发布近三十年后，我们仍在等待哪怕一个系统真正兑现 JIT 承诺的优势。我猜公认最接近的是 V8？但现实是，手工优化的 AoT（提前编译）构建仍然是性能工作的黄金标准。
ajross查看英文原文
This seems poorly grounded. In fact almost three decades after the release of the Java HotSpot runtime we're still waiting for even one system to produce the promised advantages. I guess consensus is that V8 has come closest? But the reality is that hand-optimized AoT builds remain the gold standard for performance work.
补充指出论文可能忽略了 IC 的核心价值：作为反馈给优化流水线的 profiling 数据，而非单纯的加速手段
我认为这里缺失的关键点是：JavaScriptCore（JSC）等系统不只是用内联缓存来加速动态访问，还把它当作性能剖析（profiling）的反馈来源。解释器、基线或轻度优化代码中的每个 IC 都会被监控其多态程度，并将数据反馈到优化流水线中。只把 IC 当作死胡同、不用于剖析，收益远低于让 IC 反馈剖析信息。
pizlonator查看英文原文
I think the missing piece here is that JavaScriptCore (JSC) and other such systems don't just use inline caching to speed up dynamic accesses; they use them as profiling feedback. So, anytime you have an IC in interpreter, baseline, or lightly optimized code, then that IC is monitored to see how polymorphic it gets, and that data is fed back into the optimization pipeline. Just having an IC as a dead-end, where you don't use it for profiling is way less profitable than having an IC that feeds into profiling.
支持赞赏发表负面结果，呼吁强制预注册假设并发表所有结果的研究规范
很高兴看到负面结果被发表出来，这非常重要。希望大家都能走向这样的研究流程：在研究开始前强制提交假设，并且无论结果如何都强制发表。
Voultapher查看英文原文
Love to see negative results published, so so important. Please let's all go towards research procedure that enforces the submission of the hypothesis before any research is allowed to commence and includes enforced publishing regardless of results.
质疑认为追逐 IC 微优化是死路，硬件进步已让这类编译器技巧失去意义
用动态二进制修改去追逐内联缓存的微优化是一条死路。现代 CPU 正在嘲笑我们过时的编译器技巧。也许是时候接受：聪明的 hack 跑不过硅片本身。
tsunego查看英文原文
chasing inline cache micro-optimizations with dynamic binary modification is a dead end. modern CPUs are laughing at our outdated compiler tricks. maybe it's time to accept that clever hacks won’t outrun silicon.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2025Hacker News 讨论帖203 分 · 142 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选