编程语言与软件工程2020greenlab.di.uminho.pt
不同编程语言的能效比较
Energy Efficiency across Programming Languages
入门 · 约 35 分钟读完前置知识：编程语言基础、基准测试方法、能耗测量基础
导读
这篇论文通过基准测试比较了多种编程语言在能耗、执行时间和内存使用方面的表现。结果显示，编译型语言通常比虚拟机语言和解释型语言更节能，且执行速度与能耗高度相关。不过，评论也指出其方法学存在局限，例如基准测试可能无法反映实际使用场景。
HN 关注点：不同编程语言的能源效率差异，讨论焦点包括语言选择对能耗的实际影响、基准测试方法的可靠性，以及 Java 等语言的能效表现。
后来怎么样
它让“编程语言能耗排名”成为绿色软件工程和开发者社区的常见参考，并催生了对该基准的复现与扩展测量；同时其方法学局限也被后续工作反复讨论。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
亲历Common Lisp 在能效和性能上优于其他动态语言，作者选择它因其长期稳定性和与 C/C++ 的互操作性。
Lisp（Common Lisp）以相当大的优势击败了所有其他动态语言。这就是为什么我在开发 Clasp——一个基于 LLVM 的 Common Lisp 实现，能与 C++/C 互操作（https://github.com/clasp-developers/clasp.git），用于科学编程。有了 Clasp，我们兼得多个世界的好处。我们获得了一种动态语言（Common Lisp），具有自动内存管理和强大的表达力，可以直接使用强大的 C 和 C++ 库。这三种语言都是“长寿”语言，10 年和 20 年前写的代码仍然可用。性能对我来说非常重要，过去四十年我写了很多代码。我不会在任何在表 4 中低于 Racket 的语言中开发有意义的代码，因为这些语言实现效率太低。此外，我希望我的代码能在未来多年和几十年继续使用，所以不会在任何别人可以通过更改标准来破坏我的代码的语言中开发有意义的代码。我的程序“leap”是 27 年前用 C 写的，至今仍有数千名计算化学家每天使用。但改进 leap 非常困难，因为代码很脆弱，很大程度上是因为 malloc/free 风格的内存管理（哎）。对于一种编译型、高性能、标准且经过验证具有持久力和性能的语言——Common Lisp 是最佳选择。
drmeister查看英文原文
Lisp (Common Lisp) beats all the other dynamic languages by a considerable margin. This is why I am developing Clasp - a Common Lisp implementation based on LLVM that interoperates with C++/C (https://github.com/clasp-developers/clasp.git) for scientific programming. With Clasp, we get the best of multiple worlds. We get a dynamic language (Common Lisp) with automatic memory management and enormous expressive power that can directly use powerful C and C++ libraries. All three of these languages are "long-lived" languages in that code that was written 10 and 20 years ago still works. Performance is really important to me and I have written a lot of code over the past four decades. I won't develop meaningful code in any language that falls below Racket in table 4 because these language implementations are too inefficient. I furthermore want to keep using my code over the years and decades and so I won't develop meaningful code in any language where someone else can break my code by changing the standard. My program "leap" was written 27 years ago in C and it is still being used daily by thousands of computational chemists. But it's really hard to improve leap because the code is brittle largely because of malloc/free-style memory management (brrr). For a compiled, high-performance, standard language with proven lasting power and performance - Common Lisp is the best choice.
质疑批评研究方法：纯 Python 代码未反映实际使用（实际热循环在 C 等库中），基准测试人为。
这项研究的代码在这里：https://github.com/greensoftwarelab/Energy-Languages 从代码片段来看，这项研究的一个大问题变得清晰——它没有反映像 Python 这样的语言在实践中是如何使用的。 在实践中，Python 的“热循环”位于 c/c++/fortran/cython/numba/... 中，即 Python 代码通常利用庞大的优化科学/数学/数据科学库生态系统。而研究代码主要使用纯 Python。 这是方法论上的一个问题：程序是专门为这项研究编写的，制造了一种人为情况。
montebicyclelo查看英文原文
The code from this study is here: https://github.com/greensoftwarelab/Energy-Languages From looking at the code snippets, a big issue with this study becomes clear - it doesn't reflect how languages like Python are used in practice. In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/... i.e. Python code usually makes use of a vast ecosystem of optimized science/maths/data science libraries. Whereas the study code is mainly using pure Python. It's an issue with the methodology that the programs are written specifically for this study; creating an artificial situation.
质疑认为论文无新意，基准测试不同语言算法复杂度不同，不可比较。
看在上帝的份上，我们能忽略这篇无用的论文吗？它没有新的见解。它只是拿 Benchmarks Game 来得出结论：最快的语言消耗的能量也最少。 Benchmarks Game 是一个消磨时间的有趣练习，但它不能说明任何事情。不同语言的解决方案甚至没有相同的算法复杂度。这些怎么可能比较？
nindalf查看英文原文
Please, for the love of God, can we ignore this useless paper? It has no new insights. It simply takes the Benchmarks Game and concludes that the ones that are fastest also consume least energy. Benchmarks Game is a fun exercise to kill some time on, but it doesn't indicate anything about anything. The solutions across different languages don't even have the same algorithmic complexity. How can these possibly be compared?
补充Java 能效被低估，其内存开销和惰性 GC 符合能源效率。
Java 在能源效率方面好得惊人。它被严重低估了，有时会被新的“将改变一切”的最佳编程语言取代，然而除了重写本身带来的好处外，很难有更好的结果。 此外，Java 常被诟病的负面因素——内存开销——在这里也相关：垃圾回收语言在略高于严格所需内存的开销下运行最佳。Java 的垃圾回收器相当“懒惰”，它们不会收集未使用的对象，直到被认为有必要，这符合能源效率。
kaba0查看英文原文
It’s crazy how good Java is at energy efficiency. It is criminally underhyped and are sometimes replaced by the new best PL that will change everything, and yet it is very unlikely to have better results besides the inherent one in the rewrite. Also, the often claimed negative of Java, memory overhead is relevant here — a GCd language operates best with a deliberate overhead over the strictly necessary memory. Java’s GCs are quite “lazy” in that they will not collect unused objects until it is deemed necessary, which is in line with energy efficiency.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2020Hacker News 讨论帖192 分 · 158 评
- 2022Hacker News 讨论帖79 分 · 89 评
同领域还值得读
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 分钟编辑精选