前几天在HN看到的不错文章： https://robert.ocallahan.org/2020/08/what-is-minimal-set-of-optimizations.html Zero Abstraction 虽然听起来很深奥 但其实你大概每天都会遇到：用最简单的解释方法 就是程式设计师只要专注於抽象层面的设计，例如使用各种standard library的资料结构 ，而不用去担心效能方面的问题。 听到最後一句「不用担心效能」 萤幕前的你大概就猜得出来这终究只是个理想。 其中一个阻碍就是编译器大部分时候都「看」不到程式设计师脑中的抽象结构，只能就 比较底层的结构，像是IR，做优化。 上面分享的文章就在探讨 到底哪些演算法是会帮助编译器优化这些高阶的概念 使得Zero Abstraction离理想的目标更近一些。原作者认为有这些： 1. Inlining 2. Copy Propagation 3. (Limited) Dead Code Elimination 4. Scalar Replacement (i.e. LLVM 的 SROA) 除此之外原作者则认为 Common Sub-Expresion Elimination 视情况可能有帮助 能明确回答这问题还有一个好处：如果我们在debug build (i.e. -O0) 也开启这些优化 那个 debug build 不仅有较为精确的 debug info，效能也不会差到哪边 ====== 最近几年对於高阶抽象的编译器优化开始慢慢浮上台面 其中一个最有名的例子就是 MLIR。虽然有一狗票的人看到他的名字里面有"ML"就不管青红皂白用下去，但就连 发明者Chris Lattern也强调MLIR可以解决的是更广泛的面向，也就是本文围绕的 、於高阶抽象层级的优化，有别於传统编译器都等到转换成很接近硬体的媒介後才做优化 用更大胆一点的说法就是 假如今天把 MLIR 应用於优化 C++ STL，搞不好带来的效益 会远大於目前的用途，毕竟STL已经是今日C++软体开发的骨干了 另外一个有趣的点是原文最後提到的、可能有助於debug build的效能改善。本鲁有幸 帮 PlayStation 的 compiler team 打零工倒茶(笑)，基本上他们目前最苦恼的也是一 样的问题。原因很简单：游戏开发者不可能用毫无优化的游戏来debug，因为如果没有 优化、基本上保证100%掉帧 根本玩不了 目前解决方法都朝加强Release build 的 debug info 品质。至於目前的进度的话， line number还算准确堪用，但显示被优化掉的变数目前还是一大问题（如果一个变数 被优化到完全不会放在记忆体，在debugger里面想印出他的数值会显示"<optimized out>" ）。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 169.234.228.215 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/CompilerDev/M.1596929976.A.38A.html