作為研究項目的一部分
供測試用
下一階段,考慮到硬體平台的特性,也計劃將過程間 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