编程语言与软件工程2018arxiv.org
优化编译器的未来方向
Future Directions for Optimizing Compilers
进阶 · 约 45 分钟读完前置知识：编译器优化基础、程序设计语言基础
导读
这篇论文（arXiv 1809.02161）探讨优化编译器未来的发展方向，主张编译器优化不应只追求运行时性能，还应重视编译时间等开发者体验相关的目标，并展望了全自动优化的可能路径。
HN 关注点：编译器优化的边界问题：全自动优化是否是正确方向，还是应该让程序员在源语言层面表达性能约束。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
质疑质疑全自动优化方向，主张让程序员在源语言层面表达性能约束
这些建议确实有趣，重视编译时间也是好事，但整体上我认为方向错了——追求全自动优化。如今机器对大多数场景已经足够快，生产环境用 Ruby、Python、JS 写的代码并不需要优化；而性能关键代码往往需要人工介入，全自动优化帮助不大。正如 Knuth 在 1974 年所说：理想情况下，语言应该被设计成让优化编译器能用源语言描述它的优化。一旦有了合适的语言，我们就能拥有交互式的程序操作系统。所以应该构建允许我们表达性能约束的系统/语言。
mpweiher查看英文原文
While the suggestions are definitely interesting, and the fact that compilation times are given proper attention is positive, it does seem to me that this is still pushing in the wrong direction, overall, of fully automatic optimization. We now have machines that are fast enough for many/most activities, as evidenced by production code that's written in Ruby, Python, JS, etc. For these we don't really need optimizations. On the other hand, performance critical routines tend to require human attention, and for these the approach of having the optimizations fully automated is generally less than helpful. As Knuth put it, in 1974 nonetheless: "For some reason we all (especially me) had a mental block about optimization, namely that we always regarded it a behind-the-scenes activity, to be done in the machine language, which the programmer isn’t supposed to know. This veil was first lifted from my eyes in the Fall of 1973. when I ran across a remark by Hoare [42] that, ideally, a language should be designed so that an optimizing compiler can describe its optimizations in the source language. Of course! Why hadn’t I ever thought of it? Once we have a suitable language, we will be able to have what seems to be emerging as the programming system of the future: an interactive program-manipulation system ..." -- http://www.cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf So let's have systems/languages that allow us to express performance constraints and performance-oriented transformations, and let the compiler/language assist us in doing this.
支持反驳「不需要优化」：优化高级语言运行时仍能实打实省钱
「这些场景不需要优化」这话不完全对。用高级语言写的高流量网站确实仍比低级语言高度优化的版本消耗更多 CPU 和内存，只是用高级语言省下的开发时间足以投入更多算力。但如果能进一步优化高级语言代码，就能降低硬件需求、节省成本。如果你能造一个资源占用少 10% 且兼容现有应用的稳定 Ruby VM，会有人愿意掏钱的。
michaelmior查看英文原文
> For these we don't really need optimizations. While it's true that many sites with high volume are written in high level languages, it's still true that these will require more CPU and memory than something which is highly optimized written in a lower level language. The trade-off is that it takes less developer time to write code in the high level language and the savings there are enough to invest in more computing power. However, if you can optimize code for high level languages even further, you're still reducing the hardware requirements and ultimately saving costs. If you can build a stable Ruby VM that runs with 10% fewer resources and is compatible with existing applications, I think you'll find people willing to throw money your way.
补充提出如何形式化区分编译器级与算法级优化的开放问题
稍微跑题：如何界定「编译器级优化」和「高层优化」的区别？我能区分优化 CPU 周期和优化快排的 pivot 选择，但很难把这个想法泛化/形式化。这很重要，因为需要它来给编译器设定现实、可度量的目标。
wiz21c查看英文原文
A bit off topic, but how does one frame the difference between "compiler level optimisation" and "high level optimisation" ? I can sure make a difference between optimising for CPU cycles and optimizing a QuickSort pivot search, but I have hard times generalizing/formalizing that idea. It seems important to me because it would be needed to set realistic/measurable objectives on compilers.
补充补充相关研究：约束优化在编译器后端的应用
我一位朋友最近刚完成博士论文答辩，研究的是在编译器后端（寄存器分配和指令调度）中使用基于约束的优化。
ananya_muddu查看英文原文
A friend recently defended his doctoral thesis on using constraint-based optimization in compiler backends (reg alloc and instr shed).
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
- 代码
历次讨论
- 2018Hacker News 讨论帖144 分 · 57 评
同领域还值得读
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 分钟编辑精选