[翻譯] 編譯器優化以及Zero Abstraction
前幾天在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://www.ptt.cc/bbs/CompilerDev/M.1596929976.A.38A.html
推
08/09 19:38,
3年前
, 1F
08/09 19:38, 1F
推
08/21 12:08,
3年前
, 2F
08/21 12:08, 2F