朱 浩，周博洋，盧雪山，杜溢墨

(1.軍事科學院國防科技創(chuàng)新研究院，北京 100000；2.國防科技大學計算機學院，湖南 長沙 410073；3.空軍后勤部，北京100000；4.31008部隊，北京100091)

1 引言

人工智能及其支撐技術將成為決定未來社會發(fā)展的重要因素之一，人工智能技術在感知與信息處理、指揮決策、網絡空間安全和無人系統(tǒng)等領域正發(fā)揮著越來越重要的作用。以使用GPU為代表的異構計算進行人工智能應用處理的效能更高，因此研究人員提出了CPU+GPU的異構模式，由CPU進行邏輯控制和數據轉發(fā)，而GPU則負責大規(guī)模運算，這樣的各取所長的工作方式更有利于GPU性能的發(fā)揮。

計算軟件棧是發(fā)揮GPU硬件性能的關鍵。NVIDIA公司專門針對自己生產的系列GPU設計了CUDA計算軟件棧。CUDA提供了簡單的開發(fā)工具可用于設計GPU應用程序，降低了開發(fā)難度，并與計算庫、驅動等相配合實現了程序在GPU上高效的在線編譯、提交和運行。與CUDA相比，開放運算語言OpenCL(Open Computing Language)[1]是一個面向異構系統(tǒng)的完全免費的通用標準，并且適用于多種架構的處理器。OpenCL僅僅是一個通用的API，只提供函數接口，在此基礎上衍生出了很多開源的計算軟件棧，比如AMD維護的ROCm[2]、Freedesktop維護的Mesa[3]等，便于人們應用和研究。

雖然CUDA擁有比較好的性能和市場表現，但是由于目前CUDA源碼閉源并且主要支持NVIDIA的GPU和Intel商用平臺，沒有廣泛的移植性?？紤]到未來在飛騰CPU和麒麟操作系統(tǒng)等國產軟硬件平臺上會有大量GPU計算移植和適配的需求[4,5]，本文重點研究開源的OpenCL計算軟件棧包括Mesa、ROCm(Radeon Open Computing)等，研究評估不同計算軟件棧在程序各個執(zhí)行階段的性能差異、在Intel平臺和國產平臺上的性能差異等，為OpenCL軟件棧的選型和優(yōu)化提供決策依據。

2 OpenCL計算軟件棧

2.1 OpenCL

OpenCL是第一個面向CPUGPUFPGA等異構系統(tǒng)并行編程的開放式、免費標準，也是一個統(tǒng)一的編程環(huán)境，當前最新協(xié)議為OpenCL 3.0。OpenCL協(xié)議有多種系統(tǒng)實現，目前主流計算軟件棧有Mesa和ROCm。

OpenCL應用的流程包含編譯、數據交換和執(zhí)行等多個過程，如圖1所示，具體到源碼通常包含clGetPlatformIDs(獲取平臺)、clGetDeviceIDs(獲取設備)、clCreateContext(創(chuàng)建Context環(huán)境)、clCreateCommandQueue(創(chuàng)建命令隊列)、clCreateBuffer(創(chuàng)建緩沖對象)、clEnqueueWriteBuffer(Host寫數據到GPU)、clCreateProgramWithSource(創(chuàng)建程序，為Context環(huán)境創(chuàng)建程序對象，并將Kernel源碼加載到該對象中)、clBuildProgram(編譯程序)、clCreateKernel(創(chuàng)建Kernel)、clSetKernelArg(設置Kernel參數)、clEnqueueNDRangeKernel(提交并執(zhí)行Kernel)和clEnqueueReadBuffer(數據拷貝回Host)等函數，OpenCL提供了這些函數接口的定義。而Mesa和ROCm等軟件棧的主要區(qū)別就在于以不同的方式實現了這些函數，所以性能會有差異。

Figure 1 Running process of OpenCL applications圖1 OpenCL應用的運行流程

OpenCL應用程序包含C程序代碼和Kernel程序代碼。C程序代碼負責除內核計算以外的設備初始化、數據輸入輸出、Kernel程序提交和執(zhí)行等部分；Kernel程序代碼是在GPU上執(zhí)行的計算部分。OpenCL應用程序的內核部分是通過LLVM(Low Level Virtual Machine)編譯器[6]運行時編譯(Just In Time Compile)，LLVM編譯器前端負責對程序進行語法分析、詞法分析以及優(yōu)化后轉成LLVM IR格式的中間語言；LLVM后端根據當前使用何種GPU設備來完成中間語言到GPU可執(zhí)行語言的編譯。

2.2 Mesa

Mesa(全稱Mesa 3D)是一個完全開源的設備驅動程序，支持多種GPU，于1993年8月由布萊恩·保羅提出，設計之初僅僅是為了實現OpenGL的功能。在隨后的發(fā)展中，其內容不斷豐富并加入了GLX(OpenGL extension to X)、EGL、OpenCL等功能的實現。其中實現OpenCL語言的項目叫做Clover。

Mesa Clover能夠支持OpenCL 2.2協(xié)議，對AMD 顯卡有良好的支持。Mesa Clover結構簡單，在處理數據量不大的OpenCL應用時，相比其它軟件棧有一定的性能優(yōu)勢。

2.3 ROCm

ROCm是AMD維護的成熟的完全開源的OpenCL實現，支持OpenCL 2.2。ROCm有比較完整的生態(tài)，不僅支持OpenCL計算，還可以通過HIP(Heterogenous-compute Interface for Portability)支持CUDA計算，還包含豐富的調試、性能分析和開發(fā)環(huán)境等工具，是GPU計算方向比較活躍的項目。

ROCm主要包括3個部分：ROCm 庫、ROCm平臺和ROCm內核驅動，如圖2所示。

Figure 2 Architecture of ROCm圖2 ROCm的軟件棧結構

ROCm庫包含OpenCL API和OpenCL庫，其中OpenCL API是規(guī)范中定義的標準接口，ROCm OpenCL庫就是OpenCL API的實現。ROCm平臺主要實現了異構系統(tǒng)的功能，從系統(tǒng)層面整合CPU和GPU資源，也支持AMD的獨立GPU計算。最大特點是對異構資源統(tǒng)一定義了虛擬地址空間，通過共享指針來共享數據，減少數據在不同資源間的拷貝次數。ROCm內核驅動用來支持異構系統(tǒng)的內核驅動，其主要功能包括支持任務隊列，簡化計算任務在CPU和GPU上的分布，支持異構存儲管理以及驅動間的交互。其中，AMDKFD主要負責異構計算任務的處理，AMDGPU Dirver除了支持顯示和計算以外，還提供GPU設備的初始化，為AMDKFD提供設備信息等功能。

3 國產平臺和商用平臺對比評估

本節(jié)對國產飛騰平臺和Intel商用平臺上的軟件棧性能進行對比分析，了解CPU性能對GPU應用計算的影響程度。進行平臺對比測試的環(huán)境如表1所示，本節(jié)采用了飛騰1500A 4核處理器(后文稱FT 1500A)和Intel i7 4核處理器，選擇了當前飛騰臺式機上主流、適配成熟的顯卡執(zhí)行計算，OpenCL軟件棧為Mesa 17.0。

Table 1 Test environment of Pytium and Intel platforms表1 國產飛騰平臺和商用Intel平臺軟件棧性能測試環(huán)境

OpenCL測試程序采用Black-Scholes基準程序(簡稱B-S)，該程序用于計算期權定價，數據輸入是期權數集合(為了對比更加直觀，本文將存儲浮點型期權占用的存儲空間轉化成數據量的大小)，直接反映的是數據并行處理能力。對Black-Scholes基準程序的編譯、數據讀寫、運行和完成等過程進行采樣，測試這些OpenCL接口的執(zhí)行時間以及GPU加速比(CPU計算時間/GPU計算時間)。后面各圖中X軸是將期權數轉化成數據量大小后的值，Y軸是執(zhí)行時間。

如圖3所示，Intel i7處理器的應用程序內核編譯性能是FT 1500A處理器的5倍左右，由于是采用多線程編譯，這個數據可以反映出不修改LLVM編譯器默認條件下Intel i7處理器的多核并行計算能力大概是FT 1500A的5倍。

Figure 3 Build kernel time of B-S application on Phytium and Intel platforms圖3 B-S應用在飛騰和Intel平臺上的編譯內核時間

Figure 4 Read buffer time of B-S application on Phytium and Intel platforms圖4 B-S應用在飛騰和Intel平臺上的Read buffer時間

Read buffer時間反映的是CPU從GPU讀取處理后數據的能力。如圖4所示，當數據量小于175 MB時，FT 1500A執(zhí)行時間大約是Intel i7的3.5倍；當數據量大于175 MB時，FT 1500A執(zhí)行時間大約是Intel i7的2倍。

評估內核函數在GPU上的實際執(zhí)行時間，記錄為GPU計算時間。如圖5所示，開始FT 1500A上GPU計算時間幾乎與Intel i7的相等，數據量在240 MB附近時，FT 1500A的GPU計算時間出現跳躍式大幅度增加，接近4倍，而數據量在240 MB附近時，Intel i7的GPU計算時間有小幅度增加?？紤]到這部分時間主要運行在GPU端，導致時間的差異應該是與CPU性能無關的，經過分析發(fā)現主要是由于CPU體系結構的不同，導致編譯后的內核代碼不同。在對內核代碼進行編譯時，LLVM編譯器會根據CPU體系結構的不同，編譯生成字的節(jié)碼有所區(qū)別。在Intel商用平臺上使用其他處理器運行B-S應用來測試GPU計算時間，確實沒有區(qū)別，這證實了主要跟體系結構有關。

Figure 5 GPU running time of B-S application on Phytium and Intel platforms圖5 B-S應用在飛騰和Intel平臺上GPU計算時間

為了了解是國產飛騰平臺還是商用Intel平臺上加速效果更明顯，獲得GPU執(zhí)行計算的加速比，首先將B-S應用內核函數的算法重寫并使用CPU進行計算，得到2個平臺上各自的CPU計算時間。如圖6a所示，Intel i7的性能優(yōu)勢隨著數據量的增大越來越明顯，FT 1500A的執(zhí)行時間最大時大概是Intel i7的2.8倍。用CPU計算時間除以GPU計算時間和可以得到應用程序的加速比。當數據量低于240 MB左右時，FT 1500A上的加速比高于Intel i7上的，超過20倍。當數據量超過240 MB時，Intel i7上的加速比高于FT 1500A上的，這是因為在FT 1500A上，內核的GPU執(zhí)行時間在數據量超過240 MB時出現跳躍點，性能突然變差(如圖6b所示)。整體來說，Intel i7上的加速比大概在5～10倍波動，FT 1500A上的加速比大概在4～20倍波動，最后兩者分別穩(wěn)定在5倍左右。

Figure 6 CPU running time of B-S application on Phytium and Intel platforms圖6 B-S應用在飛騰和Intel平臺上的CPU計算時間

Figure 7 Overall running time of B-S application on Phytium and Intel platforms圖7 B-S應用在飛騰和Intel平臺上的運行時間

如圖7a所示，考慮測試初始化、編譯、數據準備和GPU計算等過程的運行總時間，FT 1500A上的執(zhí)行時間是Intel i7上的3.3～5.2倍。如果不考慮初次運行的編譯時間，如圖7b所示，FT 1500A上的執(zhí)行時間是Intel i7上的2～4.1倍。

結合以上測試數據，對在國產平臺和商用平臺上進行GPU計算的性能評估總結如下：

(1)OpenCL應用的編譯時間、數據拷貝時間、GPU計算時間等，也就是GPU應用的整體性能都和CPU平臺的性能、體系結構有關。國產平臺和商用平臺2種不同CPU體系結構上的GPU計算時間(即內核函數在GPU上的執(zhí)行時間)會有區(qū)別，主要是因為內核程序編譯生成的可執(zhí)行代碼受體系結構的影響有差異。

(2)在計算數據量較小時，FT 1500A上使用GPU計算獲得的加速比更大；數據量越大尤其是超過某個值時，GPU計算時間會有不同程度的跳漲，Intel平臺上的GPU加速性能更優(yōu)。這個跳漲的時機和原因有待進一步分析。當要處理的數據量較大時，國產平臺上受制于CPU性能和體系結構編譯優(yōu)化方式等瓶頸因素，GPU計算獲取的加速收益不如Intel商用平臺。

(3)雖然大數據量計算時國產平臺上計算加速收益不如Intel商用平臺，但如果不考慮編譯時間，FT 1500A上OpenCL應用執(zhí)行時間比Intel i7 CPU上長2～4.1倍，小于FT 1500A與Intel i7 CPU本身的性能差距(這個差距大概是5倍)。在有的程序既可以使用CPU計算也可以使用GPU計算時，在國產平臺上應更多地使用GPU進行計算，減少CPU性能差異帶來的負面影響。

(4)在國產平臺上優(yōu)化OpenCL計算，應該是整個軟硬件系統(tǒng)的優(yōu)化，而不能僅僅優(yōu)化GPU硬件體系結構。

4 軟件棧對比評估

Mesa和ROCm是當下2個比較熱門的OpenCL開源計算軟件棧，本節(jié)對比了OpenCL應用在2個軟件棧上的性能表現，作為對照還增加了AMD-APPSDK軟件棧的測試，APPSDK是AMD公司維護的一個閉源的OpenCL計算軟件棧?？紤]不同平臺上的驅動和內核有差異，可能會對應用執(zhí)行產生影響，最后對驅動、內核造成的運行時間影響進行評估。

4.1 OpenCL軟件棧測試

OpenCL軟件棧測試環(huán)境如表2所示，采用了Intel i7處理器平臺，裝配有AMD中端檔次的RX460顯卡，內核版本是4.15，驅動分別是開源的amdgpu和閉源的amdgpu pro，執(zhí)行B-S應用。測試時對比的OpenCL軟件棧分別為ROCm、APPSDK、Mesa-open(Mesa，采用開源驅動)和Mesa-close(Mesa，采用閉源驅動)。

Table 2 Test environment of software stack 表2 軟件棧測試環(huán)境

如圖8所示，進行Create Buffer緩存的分配時，ROCm的執(zhí)行時間隨著數據量的增長而快速上升，其他3種軟件棧幾乎沒有變化，多次測試均是這個結果。通過對代碼分析發(fā)現，ROCm在緩存分配時會進行實際的物理分配，而其他的軟件棧只是創(chuàng)建一個mem結構體，在讀寫時才進行實際的物理空間分配。

Figure 8 Create buffer running time of B-S application on various software stacks圖8 B-S應用在不同軟件棧上的Create Buffer執(zhí)行時間

如圖9所示，對比內核程序編譯的時間，Mesa上編譯時間最長，其次是ROCm，最短的是APPSDK。經過分析發(fā)現，編譯性能的差異主要是由于LLVM編譯器在對內核源碼進行編譯生成ISA代碼過程中，編譯后端的目標組合(Target Triple)差異性導致的，比如Mesa的目標組合是(amdgcn，Mesa3d，Mesa3d)，ROCm的目標組合是(amdgcn，amd，amdhsa)。這個編譯目標組合是在LLVM編譯器里定義的，整個三元組含義是：(AMD GPU體系結構，廠商，操作系統(tǒng)環(huán)境)。根據目標組合的不同，不同的軟件棧編譯成的ISA代碼就會有差異，從而導致編譯內核執(zhí)行時間有所差距，最終導致在GPU運行內核程序的效率有差別。

Figure 9 Build kernel running time of B-S application on various software stacks圖9 B-S應用在不同軟件棧上的編譯內核執(zhí)行時間

如圖10所示，內核程序在GPU上計算時，在數據量低于240 MB時,APPSDK和ROCm的執(zhí)行時間都略高于Mesa的。對Mesa來說，GPU上的計算時間仍存在一個跳躍點，當數據量高于240 MB時，Mesa開閉源的性能都會突然變差，執(zhí)行時間達到APPSDK和ROCm的2倍。

Figure 10 GPU running time of B-S application on various software stacks圖10 B-S應用在不同軟件棧上的GPU計算時間

如圖11a所示，將主機內存數據寫入GPU存儲時,Mesa軟件棧無論開閉源驅動，它們的執(zhí)行性能都相近，都低于ROCm和APPSDK上的性能。但是，當數據量高于240 MB時，存在一個跳躍點，Mesa開源驅動上的執(zhí)行時間長于Mesa閉源驅動的。

如圖11b所示，將GPU計算產生的數據讀回主機內存上是Read buffer，與Write buffer的表現類似,Mesa的性能差于APPSDK和ROCm的。在數據量為240 MB左右時，Mesa的執(zhí)行時間有個快速增長的區(qū)間。

Figure 11 Read/Write buffer time of B-S application on various software stacks圖11 B-S應用在不同軟件棧上的讀寫緩沖執(zhí)行時間

如圖12所示，對比B-S應用從提交到執(zhí)行結束的總執(zhí)行時間，APPSDK有最好的性能表現，當數據量較小時(100 MB左右)，ROCm上的執(zhí)行時間長于Mesa上的。但是，當數據量在240 MB附近時,Mesa上的執(zhí)行時間會快速增加。

Figure 12 Overall running time of B-S application on various software stacks圖12 B-S應用在不同軟件棧上的總時間

對OpenCL軟件棧測試總結如下：

(1)應用總的執(zhí)行時間，最優(yōu)的是APPSDK，ROCm次之，然后是Mesa加閉源驅動的組合，最后是Mesa加開源驅動的組合。

(2)對GPU計算時間來說，尤其是大數據量時，APPSDK、ROCm平臺的GPU性能優(yōu)于Mesa的。APPSDK和ROCm的性能曲線是基本相同的，Mesa平臺開閉源性能曲線基本相同。這說明了LLVM編譯器針對APPSDK和ROCm的優(yōu)化更好，相同內核函數在這兩者上的執(zhí)行效率更高。

從圖10可以看出GPU計算時間，Mesa性能明顯差于APPSDK和ROCm的，并且在數據量為240 MB時會有一個跳躍點，執(zhí)行時間會明顯增長。為了證明普遍性，本文又對比了另外幾個應用的GPU計算性能。

如圖13所示，進行2D圖像卷積(Convolution-2D)測試，在Mesa上的GPU計算時間上升幅度明顯高于ROCm上的，當數據量達到240 MB附近時，也出現跳躍式增加。而ROCm上的GPU計算時間一直平穩(wěn)上升，在數據量達到280 MB時，增速僅僅有小幅度增加。這說明對于Mesa，數據量達到一定閾值時，應用的性能會有較大衰減，原因初步分析與Mesa中固定內存的創(chuàng)建方式有關，更深入的研究是下一步的工作。

Figure 13 GPU running time of 2D convolution application on various ROCm and Mesa-open圖13 ROCm和Mesa-open上2D圖像卷積測試的GPU計算時間

Rodinia srad是超聲波和雷達成像應用，用于消除局部相關噪聲，而不會破壞重要的圖像特征。Rodinia hotspot用于根據建筑平面布置圖和模擬功率測量來估算處理器溫度。如圖14所示，Mesa上的Rodinia srad GPU計算時間為ROCm上的1.97倍。對于Rodinia hotspot應用，Mesa的GPU計算時間為ROCm的3倍。進一步證實了Mesa平臺上的GPU計算性能確實不如ROCm上的。

Figure 14 GPU running time of Rodinia applications on ROCm and Mesa-open圖14 Rodina應用在ROCm和Mesa-open棧上的GPU計算時間

下面2小節(jié)對驅動、內核差異造成的運行時間影響進行評估。OpenCL應用運行依賴的OpenCL軟件棧還包括系統(tǒng)軟件棧，比如底層的驅動和內核，它們構成了一個完整的軟件棧來實現應用與硬件的交互。

4.2 開閉源驅動測試

從圖12可以看出，應用在Mesa加開源驅動上運行與Mesa加閉源驅動的相比，性能要差一些，并且隨著數據量的增大，性能差距越來越大。為了說明這種現象的普遍性，本節(jié)選擇使用另一種OpenCL應用Adi進行確認測試。Adi是針對多核CPU和GPU的基準測試套件PolyBench-ACC中的測試用例。

如圖15所示，與B-S應用的Write buffer和Read buffer類似，Adi應用在Mesa開源驅動上運行與Mesa閉源驅動上相比，開源驅動的性能要差，當數據量小時差距比較小，開源驅動上的運行時間波動大。

Figure 15 Read/Write buffer time of Adi application on various software stacks圖15 Adi應用在不同軟件棧上的讀寫緩沖執(zhí)行時間

如圖16所示，與B-S應用類似，Mesa上的Adi應用GPU計算性能比較差，并且開閉源驅動均會在240 MB數據量時出現較大波動。

Figure 16 GPU running time of Adi application圖16 Adi應用在GPU上的計算時間

根據B-S應用和Adi應用等的性能表現，總結開閉源軟件棧測試結果如下：

(1)開閉源驅動會對讀寫緩沖和GPU計算時間等過程產生影響。

(2)在數據量未超過跳躍點時，開閉源驅動執(zhí)行的總時間幾乎相等，開閉源驅動的GPU性能沒有差異，當數據量超過跳躍點后，閉源驅動的GPU性能略高于開源驅動。經過對同一時間點開發(fā)下載的開閉源驅動對比分析發(fā)現，無論是OpenCL軟件棧還是驅動閉源軟件棧的版本，相對于開源版本都比較新，廠商會優(yōu)先將一些新的特性優(yōu)化集成在閉源版本中，這是GPU廠商的市場策略，這也是閉源性能有優(yōu)勢的主要原因。

4.3 內核版本測試

這一節(jié)評估內核版本對B-S應用進行GPU加速計算的影響。內核V4.15是Ubuntu1804版本默認采用的內核，與之前的長期支持LTS內核版本有較大的改動，本節(jié)測試選擇了在4.15前后的2個內核進行對比，即Ubuntu1604.2默認的4.8內核版本與Ubuntu1804.1默認的 4.18版本。

如圖17所示，在數據量小于100 MB時，高低版本總執(zhí)行時間接近，隨著數據量增大，4.8版本的總執(zhí)行時間相比4.18版本的總執(zhí)行時間越來越長，超過300 MB時，4.8版本的總執(zhí)行時間接近4.18版本的2倍。

Figure 17 Overall running time of B-S application on various kernels圖17 B-S應用在不同內核條件下的總運行時間

總結對內核版本差異的測試，可以看出：內核版本變化對GPU計算時間影響比較微小，主要是在數據量達到一定閾值后，2個版本上的時間才有差別，新版本上的性能較優(yōu)。

4.4 總結

對第4節(jié)的測試結果總結如下:

(1)Mesa平臺上的GPU應用有一個跳躍點(數據量240 MB左右)，超過這個點，應用執(zhí)行時間會跳躍式增長；但是ROCm不存在這種明顯的跳躍點，執(zhí)行時間增長比較平穩(wěn)。Mesa與ROCm的GPU計算性能差異與算法和數據量有關，ROCm的GPU計算性能為Mesa的2.5～15倍左右(算法越復雜，數據量越大，ROCm優(yōu)勢越大)。

(2)ROCm開源平臺相對于APPSDK閉源平臺，應用總的執(zhí)行時間在數據量小時存在劣勢，存在很大的優(yōu)化空間。相比Mesa，ROCm是以后在國產平臺上進行移植和適配優(yōu)化比較理想的GPU計算軟件棧。

(3)在閉源驅動、新版本的驅動和內核上運行GPU應用運行性能有一定的優(yōu)勢，在國產平臺上進行GPU計算時盡可能選擇新版本的操作系統(tǒng)。

5 相關工作

Karimi等人[7-9]評估了NVIDIA GPU上的OpenCL和CUDA性能，對比了數據遷移性能、內核執(zhí)行時間和總的執(zhí)行時間，CUDA在某些場景下相對OpenCL有比較好的性能，但OpenCL的高可移植性決定了它是CUDA的一個很好替代。Komatsu等人[10,11]評估了OpenCL應用的性能和可移植性，OpenCL應用可以通過調優(yōu)達到理想的性能。Mukherjee等人[12]對比了2種軟件棧OpenCL和異構系統(tǒng)體系結構HSA(Heterogeneous System Architecture)，HSA是HSA基金會維護的一種異構計算軟件棧，由于HSA提供了共享虛擬內存、動態(tài)并行化等新特性，在異構平臺上相比OpenCL具有更好的性能。另外還有一些研究是關于OpenCL測試基準的設計和實現[13-15]，用于分析異構系統(tǒng)的瓶頸和優(yōu)化系統(tǒng)性能。本文主要是在國產和商用平臺上對不同OpenCL軟件棧的性能進行對比分析，從系統(tǒng)軟件棧和系統(tǒng)優(yōu)化角度進行更加全面深入的研究。

6 結束語

本文基于Black-Scholes、2D-Convolution、Rodinia等幾種測試集評估OpenCL軟件棧在不同條件下的性能表現，為GPU計算機軟件棧選型和優(yōu)化提供依據。通過對國產和商用平臺上OpenCL性能測試發(fā)現，CPU對GPU計算有比較大的影響，對GPU計算的優(yōu)化應該是從CPU到GPU、從軟件到硬件成體系的優(yōu)化。通過對比和測試不同軟件棧發(fā)現，ROCm的性能和穩(wěn)定性都優(yōu)于Mesa等軟件棧，比較適合以后在國產平臺上進行移植和優(yōu)化。閉源版本和新版本的軟件棧相對于穩(wěn)定的開源版本會有一定的性能優(yōu)勢，為版本選型提供了依據。