前幾天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://webptt.com/m.aspx?n=bbs/CompilerDev/M.1598206736.A.EF3.html 對吼有道理 差點都忘了template所造成的潛在code size膨脹 ※ 編輯: mshockwave (169.234.228.215 美國), 08/25/2020 11:24:52