如何為Rust編譯器提速

這篇文章主要介紹了如何為Rust編譯器提速，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

#68914 :  增量編譯使用「SipHasher128」哈希算法來確定自上一次編譯器調用以來更改了哪些代碼。此PR極大地改善了從輸入字節流中提取字節的過程（通過反復進行來確保它在big-endian和little-endian平臺上均可工作），在大多數情況下，編譯速度最多可提升13％。

在該 PR 中，Nicholas 使用一種簡單的移位算法，來替代之前的緩慢算法，帶來的好處是，代碼量更小，消除了很多 unsafe 代碼，性能也提升了。在代碼的 Review過程中，還討論了大小端字節序對哈希算法的影響。而 Rust 的 CI 跑在 ARM、x86 和 WASM 上運行測試，沒有大端（big-endian）平臺。但通常來說， 對于不同的 CPU 架構，Rust 默認會用對應的主機字節次序存儲整形數據，而提升性能。所以，最后的討論結果是，默認按小端序實現正確，然后留下了注釋，在大端序調用相關函數的時候，需要調用方轉換字節序。

#69050 ：Rust 的 crate 中存儲元數據（metadata）廣泛使用 LEB 128 編碼。但是Rustc 對其編解碼的速度還不夠快，這個 PR 就是減少了編解碼過程中的循環次數，從而提升了性能。并且還消除了一個 Unsafe 的使用。

作者為了這個 PR ，通過使用Callgrind進行性能分析，作者發現 clap-rs-Check-CleanIncr 是受 LEB128 編碼影響最大的基準測試+運行+構建組合。先后嘗試了 18 種不同的方法進行分析，并且其中有 10 種方法都有性能改進效果。最終選擇了現在的改進方法。

可想而知，要寫出性能極致的 Rust 代碼，還需要耐心且科學地分析才能做到。

BitCode 是 LLVM 引入的一種中間代碼，它是源碼被編譯為二進制機器碼過程中的中間形態，也就是說，它既不是源碼，也不是機器碼。

LLVM 在編譯過程中會對代碼進行優化，這個優化就是基于BitCode來做。對 BitCode 進行各種類型優化，進行某種邏輯等價的交換，從而使得代碼執行效率更高，體積更小。

關于 BitCode 更多介紹，可以查看這篇文章：https://xelz.info/blog/2018/11/24/all-you-need-to-know-about-bitcode/

Rust 在 rlib 和 dylib 中會存儲 LLVM BitCode，以便 Rustc 能執行 跨 crate LTO（鏈接時優化）。

去年，作者從 Rust 的配置文件中注意到 rustc 花了一些時間來壓縮它生成的LLVM BitCode，尤其是在 Debug 模式下。于是作者嘗試將其更改為不去壓縮 BitCode，這樣可以加快一些速度，但也顯著增加了磁盤上已編譯工件的大小。

然后 Alex Crichton （官方人員）告訴作者一些重要的事情：編譯器總會為 crate 生成目標代碼和 BitCode。正常編譯時使用目標代碼，而通過鏈接時間優化（LTO）進行編譯時則使用BitCode。用戶只能同時而選一，因此生成兩種代碼通常浪費時間和磁盤空間。

于是作者發了一個 RR #66961，希望從 rlib 中不要存儲 LLVM BitCode ，否則會導致增量編譯的緩存過大。然而這引起了廣泛的討論，經歷了七八個PR 重構之后，最終在 #71323 解決了此問題。

在 Debug 模式下，性能提升了 18% ，rlibs 磁盤占用縮減了 15% 到 20%。如果沒有用 Cargo 而直接使用 rustc，則需要加 -Cbitcode-in-rlib=no 才能應用該特性。

#67079:  改進用于熱調用模式（hot calling pattern）的 shallow_resolved 函數，性能提升 2%。

#67340: 縮減 Nonterminal 字符（一般可認為是變量，可被替換的符號）大小（到40字節），在構建 serde_derive 的時候大量降低了 memcpy  的調用。性能提升 2% 。

#68694:  減少了InferCtxt中對 RefCell結構的借用，性能提升 5%。

#68848:  編譯器的宏解析代碼包含一個循環，該循環在每次迭代時實例化一個大型的（Parser類型的）復雜值，但是這些迭代中的大多數并沒有修改該值。此PR更改了代碼，因此它在循環外初始化了一個解析器值，然后使用Cow避免 Clone 它（修改迭代除外），從而使html5ever基準測試速度提高了15％。（比較有意思的是， 作者說他經常用 Cow，但是他從來卻記不住關于 CoW 的使用細節，每次只能去翻文檔。。

將 LLD （LLVM 4.0 引入的）作為鏈接器，可以將鏈接的時間成倍地提升。然而，  issues 39915 報告了一個 Bug，導致至今 LLD 都無法成為 rustc 的默認鏈接器。

LLD 的特色：

1. 交叉編譯非常友好（重點在于嵌入式目標）。

2. 速度非常快。對于增量編譯來說，鏈接時間會占編譯時間的一大部分，因此能把這個時間減半相當重要。

當前 Rust 和 LLD 的狀態：

1. Rust 以二進制文件發布了一個 lld 的副本，rust-lld，可以用于大多數平臺

2. rust-lld 默認以 裸機（bare metal）為目標

3. rust-lld 默認用于 wasm

4. 可以使用“ -C linker-flavor”明確要求使用 rust-lld

在其他地方（Linux/ Mac/ Windows）使用 LLD 的問題：

1. lld 的 macOS 后端崩潰了，雖然已經開始重寫，但還太早期

2. 在linux / unix平臺上，不應直接調用ld / lld。而應該通過系統c編譯器（即gcc）來調用鏈接器，鏈接器的職責是發現像crt1.o這樣的系統符號并將其提供給ld。這意味著不能“僅僅”使用rust-lld，而必須將其輸入gcc / clang 等等。

3. Windows-msvc顯然還可以，并且似乎在后端使用rust-lld的支持有限，但是Rust 官方還不清楚在這里需要做什么。

4. Windows-mingw似乎與linux / unix大致類似，除了可能會得到一個古老的GCC，而且事情有些古怪，因為偽Windows-Linux并不是經過嚴格測試的配置？

更一般地來說，lld是新事物，它不是大多數操作系統的默認設置，如果我們在更多地方使用它，幾乎可以肯定會出現隨機的復合錯誤。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“如何為Rust編譯器提速”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!