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

看板CompilerDev作者mshockwave (夏克維夫)時間5年前 (2020/08/24 02:18)推噓4(4推 0噓 4→)

留言8則, 5人參與討論串1/1

前幾天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

08/24 08:01, 5年前 , 1^F

08/24 08:01, 1^F

推

NYCU

08/24 11:23, 5年前 , 2^F

08/24 11:23, 2^F

→

NYCU

08/24 11:25, 5年前 , 3^F

08/24 11:25, 3^F