前幾天在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/m.aspx?n=bbs/CompilerDev/M.1596929976.A.38A.html