这篇文章/论文讨论的是 Lua 和 LuaJIT 的能耗表现，而不只是传统意义上的速度快慢。PUC Lua 是 Lua 的官方参考实现，LuaJIT 则是带 JIT（即时编译）的高性能实现；评论里还提到 Are-we-fast-yet 这类基准套件，用来更贴近动态语言运行时的实际表现。讨论延伸到了 Python、Ruby、V8 等运行时优化，以及是否应该把 Joules、Watts 直接纳入性能指标。标题本身还在玩《The Dark Side of the Moon》的双关，因为 Lua 在葡萄牙语里就是“月亮”。
有人认为文章结果有意思，但测试设计不够令人信服。新旧 LuaJIT 版本几乎没有看到明显提速，甚至看起来还有倒退，因此结论和直觉不太一致。评论者怀疑作者用的是一组比较随意的 microbenchmark，而不是更系统的 Are-we-fast-yet 基准套件。还提到自己用同类基准测过 Lua 和 LuaJIT，版本差异往往比文章显示的更明显。
讨论的核心是：软件优化到底该不该把能耗当成和速度同等重要的指标。有人讽刺说，客户端代码省下几瓦电，和数据中心里为 LLMs 烧掉 Gigawatts 的现实相比，显得非常有限。也有人主张，计算机科学里的性能评估应该直接写进 Joules 或 Watts，至少训练和推理都应看每单位能耗的产出。另一部分评论则把这种“绿色”叙事看成典型的技术或管理层口号化包装，带着明显的调侃意味。
有评论从工程实践角度肯定 Lua 的价值，尤其是它很容易和 compiled language 搭配使用。做法通常是把最热的 hot path 下沉到更高效的语言，其余逻辑留给 Lua 来保持灵活性。也有人认为未来的 JIT 工作可能会更重视 energy consumption，而不只是纯速度，Python 这类语言也可能从中受益。整体上，这是一种把性能、能耗和可维护性一起考虑的务实视角。
有评论把话题扩展到 Python、Ruby、Rust、C、C++、Zig、Go、JVM 语言和 C# 的横向比较。观点是编译型语言通常会在性能上明显优于 Python 和 Ruby，而后两者不仅慢，还被批评在 type safety 上问题更多。相对地，JavaScript 却被认为出人意料地快，原因是 V8 等运行时做了很多优化。这个视角把语言设计、运行时实现和能耗效率绑在了一起。
不少人注意到标题是在玩双关：Lua 在葡萄牙语里是“月亮”，所以“The Green Side of the Lua”明显在戏仿 “The Dark Side of the Moon”。有人直接用葡萄牙语接梗，也有人顺手确认这个出处。这个小梗让原本偏技术的话题多了一层流行文化色彩。
LuaJIT: Lua 的 JIT 实现，运行时把热点代码编译成机器码，常用于提升速度，也可能影响能耗。
PUC Lua: Lua 的官方参考实现/解释器，常被拿来与 LuaJIT 做版本和性能对比。
JIT: 即时编译（Just-In-Time Compilation），在程序运行时动态生成机器码以优化性能。
Are-we-fast-yet: 一个动态语言基准测试套件，用来比较不同语言和运行时的性能表现。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。