[分享] 實作在GCC上的平行化編譯

[mshockwave (夏克維夫)]

前幾天GCC社群有個不小的新聞：新的 "-fparallel-job=<N>" 選項可以讓編譯流程

本身平行化

有別於許多近代 build system 早已提供的檔案層級平行化(i.e. 把個別檔案的編譯工作

都到獨立的一個thread)

編譯器本身的平行化(i.e.把編譯器內部的工作平行化)一直以來都沒有登上

主流 因此我聽到這個消息以後非常的興奮


事實上這個計畫大概在去年底就有個雛形了：

https://youtu.be/jd6R3IK__1Q

我也會就這個影片做講解(P.S.雖然內容很讚但這個演講本身的品質...有待加強XD)

這個計畫最大的動機是大型檔案的編譯速度太慢 同時也是前述build

system檔案層級平行化無法解決的問題


如果把GCC各部分(e.g. frontend, backend)的處理時間攤開來看 可以得到以下分佈：

https://imgur.com/35KzIRj

其中很明顯的RTL，也就是backend/code generation的部分花最多時間

第二多的則是target independent、intra-procedural的優化與analyses

(也就是GIMPLE)

雖然RTL佔的時間最多 但該計畫的作者認為 GIMPLE 比較好改

所以就先嘗試將每個function丟到獨立的thread裡面做 GIMPLE 優化

https://imgur.com/bpah6Q4

當然就如影片裡面所示 有一堆全域的資料結構因為race condition的緣故要修改


最終實驗結果如下：

https://imgur.com/Blb6Tye

5~6%的加速...雖然已經很好了 但如果把這項技術也用在RTL上的話...

https://imgur.com/wD9422B

30~60%的加速 這個就真的蠻驚人了

雖然我很想吐槽：繞了一大圈你還不是要平行化RTL （笑

========

即便得到了一個如此亮眼的數字 我想最大的問題在於：

通常你有一個超超超大的檔案 你會想直接把他切小一點 而不是那麼費工地平行化編譯器

我認為並不是這想法本身有問題 而是因為用multi-threading本身的overhead還蠻大的

所以你的檔案真的要超級超級大 用這個技術才划得來

但如果如此的大 就像上面所說的：直接切小一點會比較快

又或者是說：會產生如此大檔案的情況少之又少 這種corner case 真的值得你花那麼多

時間去研究以及維護嗎？別忘了GCC是一個持續成長的開源專案 如果這項技術導致以後

一些更重要的功能難以實作 難保不會有人質疑這技術的必要性


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 169.234.228.215 (美國)
※ 文章網址: https://www.ptt.cc/bbs/CompilerDev/M.1598206736.A.EF3.html
推 heap5566: 弱弱的問一句 跟原本的-j4 差在哪裡啊？
推 NYCU: make -j4是在Makefile有多個獨立工作的情況下平行
→ NYCU: e.g. 對多個不同的.c檔gcc 最後再link多個.o檔
→ Lipraxde: 還是有需要的吧？寫 template、header only 等都可能會
→ Lipraxde: 讓 code 膨脹。若說是大檔案的話，拆散後為了效能去開
→ Lipraxde: LTO 不也有點奇怪？
對吼有道理 差點都忘了template所造成的潛在code size膨脹
※ 編輯: mshockwave (169.234.228.215 美國), 08/25/2020 11:24:52
推 JameC: -j4 應該就是一開始講的、檔案層級的平行化吧？
推 akasan: gcc的global var 真的多到哭爸...