作為研究項目的一部分 已經開始為 GCC 添加一項功能，允許將編譯過程劃分為多個平行執行緒。 目前，為了提高多核心系統上的建置速度，make 實用程式使用啟動單獨的編譯器進程，每個編譯器進程都會建置一個單獨的程式碼檔案。 新專案正在嘗試在編譯器層級提供並行化，這將有可能提高多核心系統的效能。
供測試用 GCC 的一個單獨的並行化分支，它提供了一個新參數「—param=num-threads=N」來設定執行緒數。 在初始階段，我們將過程間最佳化轉移到單獨的線程中，每個函數循環都會呼叫這些線程，並且可以輕鬆並行化。 GIMPLE 操作負責獨立於硬體的最佳化，評估函數之間的交互，這些操作被放置在單獨的線程中。
下一階段，考慮到硬體平台的特性，也計劃將過程間 RTL 最佳化轉移到單獨的執行緒。 之後，我們計劃實作應用於函數內部程式碼的過程內最佳化 (IPA) 並行化，而不管呼叫的具體情況。 目前的限制環節是垃圾收集器，它添加了一個全域鎖，在多執行緒模式下運行時禁用垃圾收集操作（將來垃圾收集器將適配GCC的多執行緒執行）。
為了評估效能變化，我們準備了一個測試套件來組裝 gimple-match.c 文件，其中包括超過 100 萬行程式碼和 1700 個函數。 在具有5 個實體核心和8250 個虛擬核心（超線程）的Intel Core i4-8U CPU 的系統上進行的測試表明，程式內GIMPLE 優化的執行時間從運行7 個執行緒時的4 秒減少到2 秒，運行3 個線程時減少到4 秒。線程，即所考慮的組裝階段的速度分別提高了 1.72 倍和 2.52 倍。 測試還表明，使用具有超線程的虛擬核心不會提高效能。
整體建置時間減少了大約 10%，但根據預測，並行 RTL 最佳化將實現更切實的結果，因為此階段在編譯過程中需要花費更多時間。 大約在RTL並行化之後，總彙編時間將減少1.61倍。 此後，透過並行 IPA 優化，可以將建置時間再減少 5-10%。
來源： opennet.ru