山東大學RISC-V公共開放平臺開發記錄

RISC-V編譯

2 編譯優化策略

2.1 RISC-V GCC工具鏈的（–mcmodel=）選項

目前RISC-V GCC工具鏈認為，在實際的情形中，一個程序的大小一般不會超過4GB的大小，因此在程序內部的尋址空間不能超過4GB的空間。而在64位的架構中，地址空間的大小遠遠的大于4GB的空間，因此針對RV64架構而言，RISC-V GCC工具鏈定義了（–mcmodel=）選項用于指定尋址范圍的模式，使得編譯器在編譯階段能夠按照相應的策略編譯生成代碼。其有效的選項值如下：

· -mcmodel=medlow

· -mcmodel=medany

注意：

· 在RV32架構中，整個地址空間的大小就是4GB，因此（–mcmodel=）選項的任何值對于編譯的結果都無影響。

· RISC-V GCC工具鏈在未來可能也會支持大于4GB的尋址空間。

medlow和medany兩個選項的含義分別解釋如下。

1.（-mcmodel=medlow）選項

（-mcmodel==medlow）選項用于指示該程序的尋址范圍固定只能在-2GB至+2GB的空間內。注意：地址區間沒有負數可言，-2GB是指整個64位地址空間最高2GB地址區間。
由于此模式的尋址空間是固定的-2GB至+2GB的空間內，因此編譯器能夠相對生成比較高效的代碼，但是由于尋址空間固定，對于整個64位的大多數地址空間都無法訪問到，用戶需小心使用。

2.（-mcmodel=medany）選項

（-mcmodel==medlow）選項用于指示該程序的尋址范圍可以在任意的一個4G空間內。由于此模式的尋址空間不是固定的，所以相對比較靈活。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ByJOEYsP-1654330904936)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image002.gif)]

2.2 SIFIVE的解決方案

為了確保RISC-V編譯器的命令行界面在未來易于擴展，SIFIVE決定采用這樣一種方案：用戶用三個參數來描述他們要編譯的RISC-V目標。

-march=ISA選擇目標架構。這將控制哪些指令和寄存器可供編譯器使用。

-mabi=ABI 選擇目標ABI。這控制了調用慣例（哪些參數在哪些寄存器中傳遞）和內存中的數據布局。

-mtune=CODENAME選擇目標的微架構。這將告知GCC每條指令的性能，使其能夠執行針對目標的優化。

-march參數

-march參數基本上是由RISC-V用戶級ISA手冊定義的。-march控制指令集，允許編譯器從中生成指令。這個參數決定了一個程序可以運行的實現集：任何符合RISC-V標準的系統，只要包含了用于編譯程序的-march值，就應該能夠運行該程序。

說得更具體一點。RISC-V用戶級ISA的2.2版本定義了目前工具鏈支持的三種基本ISA。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RYrhKdv3-1654330904938)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image002.gif)]

參數-mabi

GCC的-mabi參數指定了生成的代碼所符合的整數和浮點ABI。就像-march參數指定了生成的代碼可以在哪些硬件上運行一樣，-mabi參數指定了生成的代碼可以與哪些軟件鏈接。我們使用整數ABI的標準命名方案（ilp32或lp64），并附加一個參數單字母來選擇ABI使用的浮點寄存器（ilp32 vs ilp32f vs ilp32d）。為了使對象能夠被鏈接在一起，它們必須遵循相同的ABI。

RISC-V定義了兩個整數ABI和三個浮點ABI，它們一起被視為一個ABI字符串。整數ABI遵循標準ABI命名方案。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-RLPs15Y6-1654330904939)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image004.gif)]

就像ISA字符串一樣，ABI字符串被串聯起來，并通過-mabi參數傳遞給GCC。為了解釋為什么ISA和ABI應該被當作兩個獨立的參數，讓我們來看看少數幾個-march/mabi的組合。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-uymHNWeX-1654330904939)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image006.gif)]

-mtune參數

在指定目標時涉及的最后一個編譯器參數是最簡單的。雖然-march參數會導致系統無法執行代碼，-mabi參數會導致對象之間的不兼容，但-mtune參數應該只改變生成代碼的性能。就目前而言，我們確實沒有任何針對RISC-V系統的調諧模型。除非你剛剛給我們的GCC端口添加了一個新的調諧參數，否則你可能不應該費力地對這個參數做什么。

2.3 GCC優化

RISC-V是一個新的開源指令集架構(ISA)，在2016年12月生產了第一批量產處理器。

2016年9月，它制造了第一批大規模生產的處理器。它的重點是

它專注于經濟性和性能，與其他開源架構不同的是

架構的不同之處在于，它沒有一個允許供應商自由設計、生產和銷售RISC-V的版權許可。

簽署、制造和銷售RISC-V芯片而不需要任何費用，也不需要分享他們對參考實現的修改。

他們對架構的參考實現的修改。

本論文的目標是評估GCC和LLVM/clang編譯器的性能。

本論文的目的是評估GCC和LLVM/clang編譯器對RISC-V目標的支持性能以及它們為該架構進行優化的能力。優化架構的能力。性能的評估將從CoreMark和Dhrystone中進行。

性能將從CoreMark和Dhrystone進行評估，這兩個都是流行的工業標準這，用于評估嵌入式處理器的性能的基準。它們將在GCC和LLVM/clang編譯器上以不同的優化水平運行。

級別上運行，并與ARM架構的每時鐘性能進行比較。與RISC-V相比，ARM架構更加成熟，但也是最類似的廣泛使用的CPU架構。對RISC-V目標的編譯器支持仍在開發中。

的編譯器支持仍在開發中，本論文的重點將是目前GCC與RISC-V的性能差異。

GCC和LLVM編譯器在這個架構上的差異。結果顯示，GCC上的-O2和-O3優化級別的-O2和-O3優化水平與我們的ARM參考相比表現非常好。在較低的-O1優化級別和-O0（沒有優化）以及-O，也就是帶有優化的-O0，以生成更小的可執行代碼大小。CoreMark基準測試中，GCC在-O1時的性能為46%，在-Os時為8.2%，在-O0時為9.3%，結果相似。

在Dhrystone中，除了在-O1上的表現與ARM一樣好之外，GCC的表現比ARM差很多。，RISC-V的GCC在CoreMark中的性能是ARM的9.2%，在Dhrystone中的性能是ARM的11%。在CoreMark中的性能是ARM的9.2%，在Dhrystone中是11%，另一方面，LLVM/clang在試圖編譯我們的CoreMark基準時崩潰了。而在Dhrystone上，優化選項的影響非常小。

而在Dhrystone上，優化選項對性能的影響非常小，它的性能是GCC的6.0%。

在Dhrystone上，優化選項對性能的影響很小，使其在-O3上的性能是GCC的6.0%，在-O3上的性能是ARM的5.6%，所以即使有優化，它仍然比沒有優化的GCC慢。

總而言之，考慮到RISC-V與GCC編譯器在較高的優化水平上的表現，RISC-V的性能非常好。RISC-V架構是如此年輕。然而，在較低的優化水平上確實有改進的余地。這也可能會提高高優化級別的性能。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JEoUiJSA-1654330904940)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image008.gif)]

在較高的優化級別上，GCC的表現確實相當好，例如-O3和-O2，但在較低的優化水平上似乎有一些問題。而較高的優化級別表現良好，由于性能在生產中是最重要的

，你可以認為GCC的支持對于生產來說已經足夠快了，但是當在匯編級別上進行調試時

級別的調試時，或者你在開發過程中需要更快的編譯時間時，可以考慮使用GCC。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-a9sfWEqr-1654330904941)(file:///C:/Users/Jeremiah/AppData/Local/Temp/msohtmlclip1/01/clip_image010.gif)]

RISC-V上的GCC在較高的優化水平上表現非常好，但在較低的優化水平上則明顯較慢。但在較低的優化水平上卻明顯地慢了下來。-O1優化比Dhrystone的-O0快16.6倍，這在其他架構上是不正常的。但更高的優化級別，如-O2和-O3對于這樣一個年輕的架構來說，非常有競爭力，令人印象深刻。架構來說是相當了不起的。

2.4系統級優化

l 處理器利用率提升

處理器中的性能優化主要體現在其利用率的提升。處理器利用率反映了處理器有效工作時間在總運行時間中的占比,是一項描述處理器繁忙程度的指標。減少處理器空閑等待的時間,提升處理器利用率,將推動系統整體的計算能力或數據處理能力的提升,使系統能夠在更短時間內完成既定工作,或者在相同時間內完成更多工作。

“馮·諾依曼瓶頸”是影響 CPU 利用率的一類典型問題。在馮·諾依曼結構[79]的計算機系統中,指令與數據被不加區分地存放在內存,使得取指令和數據不能同時進行,否則將引起訪存混亂。CPU 在執行運算前后,都需要額外的時間等待數據完成存取,而不能一直處于工作狀態。因此,馮·諾依曼結構中的 CPU 存在一個相對較低的利用率上限,無論硬件制造工藝如何提升,都無法再獲得更高的 CPU 利用率。

相應地,在 2017 年,包云崗等人提出一種標簽化馮·諾依曼體系結構 LvNA(labeled von neumann architecture),在經典馮·諾依曼結構上增加了一套基于標簽機制的可編程接口,允許向硬件傳遞更多軟件信息,使硬件可以根據軟件需求動態調整管理策略。2019 年,該團隊主導的“標簽化 RISC-V”開發項目,基于RISC-V Rocket Chip 實現了 LvNA,顯示了 RISC-V 在促進敏捷開發、提升編碼效率方面的優勢。在 2021 年, Schuiki 等提出了一種輕量級的 RISC-V 擴展“流語義寄存器(stream semantic registers,簡稱 SSR)”,允許在任何指令中編碼加載和存儲操作,而不再需要依賴顯式的加載與存儲指令,從而給出了一種解決單發射處理器中存在“馮·諾依曼瓶頸”、影響 CPU 利用率問題的方案。實驗結果顯示,采用 SSR 擴展的處理器比起未采用的相同處理器,順序代碼單核心運行速度提升 3 倍,即,集群中實現相同的性能可減少 3 倍的核心數目;多核心集群的

能效提高 2 倍,指令獲取的數量減少 3.5 倍,指令緩存功耗減少 5.6 倍。

l 內存優化

內存的設計直接制約著系統整體的組織形式和工作方式,在數據存儲、通信、同步、處理效率等多方面都對系統有關鍵性的影響。因此,內存優化問題始終是系統性能研究的一大重點。

例如,多核處理器中,隨著芯片上核心數量的增加,會出現“緩存行乒乓”問題,即,當多個 CPU 共享同一緩存行中的變量時,不同 CPU 對該變量的頻繁讀寫會導致其他 CPU 的緩存行頻繁失效。共享內存中,硬件緩存一致性范式的線程同步算法,其性能擴展問題會受到緩存行乒乓的阻礙。2019 年,Dogan 等人為了解決多核處理器的緩存行乒乓問題,提出了一種針對數據的硬件內移動計算(moving computation,簡稱 MC)模型,該模型將共享數據固定在專用核上,以實現數據局部性優化。研究人員還在 RISC-V 上建立了多核仿真環境,評估了 MC 模

型在最多 1024 核尺度下的性能擴展優勢。評估結果顯示,與自旋模型、原子模型等現有模型相比,對每個數據點標準化的完成時間平均分別提升了 60%、27%。

擴展基全局地址空間(extended base global address space,簡稱 xBGAS)是 2018 年 Leidel 等人為了解決可擴展的高性能計算架構在操作離開單個設備域時常常遭遇不必要的延遲的問題,所提出的一種 RISC-V 指令集微架構擴展。該擴展可以為常見的高性能計算操作提供緊耦合的支持。由于其提供了從基本指令訪問全局共享內存地址空間的可能性,從而開創了一條系統優化的新思路,出現了更多以 xBGAS 為基礎的研究。

例如,2019 年 Williams 等人在 xBGAS 的基礎上,提出了一種構建集體通信庫的 RISC-V 微架構擴展方案,給出了它的初始 API 設計和實現,以及底層算法。這項研究的目的是在分布式地址空間模型中,將更直觀的界面與更高的性能結合起來,以解決軟件開發人員很難適應并行編程方法,尤其是分布式地址空間中的并行編程問題。

2020 年 Wang 等人提出了一種遠程原子擴展(remote atomic extension,簡稱 RAE)的設計,為基于 RISC-V SA 架構的遠程原子操作提供了內在的 ISA 級指令和架構支持,以改善高性能計算(high performance computing,簡稱 HPC)系統的性能。

l 通信延遲緩解

通信是連接系統各組件、各成分之間的信息交換過程,通信延遲將推遲目標獲得所需信息的時間,從而增大其空閑等待時間,造成整體用時延長、目標利用率降低、或者能量空耗。緩解通信延遲,除了期待相關硬件制作工藝的改進外,提升系統的并行能力、掩蓋通信延遲的不利影響也是一種可行的做法。

)系統的性能。

l 通信延遲緩解

通信是連接系統各組件、各成分之間的信息交換過程,通信延遲將推遲目標獲得所需信息的時間,從而增大其空閑等待時間,造成整體用時延長、目標利用率降低、或者能量空耗。緩解通信延遲,除了期待相關硬件制作工藝的改進外,提升系統的并行能力、掩蓋通信延遲的不利影響也是一種可行的做法。

這方面,Morais 等人在 2019 年提出了一種將任務調度硬件加速器與通用 CPU 緊密集成的體系結構,以減少通信延遲及運行開銷,從而提高與任務調度并行的應用程序的性能。他們開發了硬件加速的輕量級任務調度運行時環境 Phentos,允許任務調度軟件通過自定義指令與硬件任務調度器和CPU直接進行交互,以最大限度減少硬件任務調度器和 CPU 之間的通信開銷。Morias 等人認為,任務并行系統的性能會受到自動依賴推理和準備運行任務調度相關開銷的限制,而用于提高運行時性能的硬件加速器往往具有較高的 CPU 通信開銷,因此他們希望通過這樣的設計,來解決 CPU 通信的高開銷問題。

總結

以上是生活随笔為你收集整理的山东大学RISC-V公共开放平台开发记录3的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。