基于通用多核處理器的5G 應用并發場景行為分析①

張亞琳, 李 浩, 胡 驍, 梁 卓, 潘彥鵬

(中國航天科技集團有限公司第一研究院 戰術武器總體技術部, 北京 100076)

數據中心將在未來迎來5G 業務[1], 其對響應時間的要求無比嚴格, 通常要求精確到微秒級[2]. 人們對未來5G 的期望遠遠高于現有的4G 網絡. 一方面, 隨著移動互聯網和物聯網的發展, 人們對用戶體驗提出了更高的要求. 另一方面, 隨著5G 在工業互聯網、車聯網、企業網的深入應用, 許多場景對通信時延、通信的可靠性和安全性提出了新的要求[3]. 另外, 運營商希望以更好的整體持有成本來應對5G 帶來的大帶寬, 海量流量, 多樣性等特征, 其核心在于計算系統能夠有更強的處理能力, 包括峰值能力和對多樣業務的適應能力.

基于專用處理器的傳統基站具有覆蓋范圍窄, 難以增加頻譜效率以及軟硬件方案固化等問題, 不能適應5G 時代對通信的強實時、大帶寬和升級換代便利等要求. 而數據中心采用云化的處理架構, 并將專用處理器替換為通用處理器, 可以使所有虛擬基站共享各項資源, 處理資源可以動態調度以適應不同場合, 通用處理器近年來在處理能力以及功耗方面的技術進展巨大, 且具有很好的靈活性, 能夠應對各種復雜業務[4]. 所以, 出于處理能力、靈活性、多樣性以及費用的考慮,5G 應用由傳統基站承載轉向數據中心部署成為趨勢.

5G 應用在數據中心的執行行為分析存在以下兩點挑戰.

(1) 無開源5G 應用作為合適的研究對象, 而針對4G/3G 卻有很多較為成熟的開源實現, 但這些應用性能較差, 不能反映真實場景和應用特征.

(2) 行為分析的復雜性. 應用單獨執行行為與所處平臺特征相關, 共同運行行為則與共享資源相關, 需結合種類繁多的處理器特征參數及共享資源進行分析.

多核/眾核芯片在數據中心中的普及, 使得研究人員開始關注到, 共同運行的程序之間會對共享資源產生競爭, 從而導致程序執行效率降低[5]. 針對刻畫應用之間對共享資源的競爭程度, 進而預測出應用在不同場景下的性能表現, 研究人員從基于統計學習和基于深度學習兩個方面開展性能預測模型的構建. Subramanian 等人建立了精確性能預測模型, 用于預測由于內存競爭造成性能損失[6]; Tang 等人使用統計模型建立了內存帶寬和作業性能之間的關系[7]; 研究人員還采用諸如隨機森林回歸模型[8]、協同過濾算法[9]、統計分析[10]、機器學習[11]、深度神經網絡[12]等方法完成從作業運行時信息到作業性能的映射. 目前研究存在的問題主要有兩點: (1) 主要選取應用的某一個特征進行分析, 如內存帶寬和Cache 失效率, 但應用的特征是多方面的, 某個角度的預測可能存在不夠準確的問題;(2) 研究人員的關注重點在于在線型業務, 對5G 等高實時應用未做針對性深入研究.

本文結合多核共享緩存、處理器執行部件和復雜硬件參數, 全面分析5G 應用的行為特征, 得出其對存儲和執行部件的資源占用情況. 然后在多線程模式下,分析多個并發體之間的性能干擾來源, 最后得出5G 應用在數據中心的合理部署方案. 主要貢獻如下.

(1) 結合體系結構特征分析應用執行行為. 5G 應用下行過程的物理層處理流程是計算密集型的, 最高端口利用率90%, 基本無數據復用, 訪存不密集, QoS(quality of service)要求極其嚴格.

(2) 以性能最佳化部署為目標, 評估5G 應用混合執行行為并給出部署建議. 5G 應用只能獨占機器執行;不超過處理器物理核數的情況下可以盡可能多部署線程; SMT 嚴重影響性能因此不宜采用; 同時TurboBoost的影響不可忽視.

(3) 選取OpenLTE 作為5G 應用的代表性benchmark進行分析, 由于開源的OpenLTE 性能很差, 在性能分析時不能反映真實場景和行為特征, 因此本文首先根據通用處理器的特點對其代碼實現進行了優化, 取得了2.5 倍性能加速比.

1 5G 應用優化

1.1 OpenLTE 的代表性

OpenLTE[13]實現的是4G 基站功能, 雖然4G 網絡與5G 網絡在性能和實現關鍵技術方面存在差異, 但是OpenLTE 仍可作為研究5G 應用下行過程物理層的樣本對象, 具體敘述如下.

5G 業務相比4G 業務, 兩者部署方式及實現技術的差異主要表現在3 方面: (1) 網絡架構. 5G 的網絡設計相比4G 網絡采用成本高效的密集布置, 更加簡化的核心網絡, 支持動態的無線拓撲的網絡功能虛擬化技術[14,15]. (2) 無線空口技術的演進, 從無線協議棧的各個層次改進, 對改善5G 業務性能具有重大幫助[16]. (3) 運營網絡管理. 運營商需要提供一個高效的資源利用、靈活的資源調配、精細和智能化的網絡管理平臺.

綜上所述, 4G 與5G 業務的不同之處主要在于網絡結構及關鍵協議的具體實現, 而針對本文要研究的5G 業務下行過程的物理層, 5G 應用和4G 應用在關鍵處理過程上仍保持一致, 需要完成冗余校驗、編解碼、調制、解調、FFT 和多天線映射等工作, 雖然具體協議版本存在差異, 但是關鍵操作相似, 所以OpenLTE 可以作為研究5G 應用基站側下行過程物理層的參考對象.

1.2 OpenLTE 的代碼特征

OpenLTE 代碼主要的功能是做數據比特流的傳輸、分割、整合、特定格式編碼、變換碼率和調制等操作. 圖1 為處理流程.

圖1 OpenLTE 程序流程圖

從數據結構來說, 主要是字符數組和字符矩陣. 輸入和輸出數據是長串字符數組, 而在中間變換碼率等操作時, 會用到矩陣來實現不同維度的編碼轉換.

從算法和操作的角度, 通信處理過程算法大多是位運算的復雜疊加以及數據在不同形式的數據結構和不同的傳輸單位間的賦值操作, 以及數據在不同坐標系間的轉換操作.

1.3 OpenLTE 優化方法

本文的代碼優化將從訪存優化、位運算優化、分支語句優化、結合數據分布特征優化以及消除耗時運算操作5 個方面進行[17].

1.3.1 訪存優化

經分析, OpenLTE 代碼中有PreCoder, Concatenation, Layer Mapper, Rate Match, Turbo Encode 和Segmentation 六個模塊均存在大量連續的賦值操作, 且操作的數據量大, 可采用SIMD 訪存優化方法[18]. SIMD加速部件的優勢一方面體現在可以增加數據操作寬度;另一個優勢是減少了指令數, 極大提升程序的性能. 可采用 Intel Intrinsic 指令集中提供的_mm256_loadu_si256 和store 指令進行256 bit 的并行load/store 操作[19].

優化后代碼如代碼1 所示. 這段操作中數組是char型, SIMD 指令可同時進行32 個數的load/store, 由于數據在內存和高速緩存是連續存放的, 可以利用一個緩存行數據的空間局部性, 同時指令數大大減少, 實測加速比為12.5 倍, 指令數減少為原來的1/27.

代碼1. Concatenation SIMD 優化-訪存寬度增加//before optimization while r < N_codeblocks do for j:= 0 to col step 1 do f_bits[j] := e_bits[j]//after optimization while r < N_codeblocks do for j:= 0 to col step 32 do ymm0 := _mm256_loadu_si256((__m256i *)(e_bits )) _mm256_storeu_si256((_m256i *)&f_bits[k], ymm0) k := k + 32;

1.3.2 位運算并行化

通信信息處理過程中的算法很多都是位運算的操作, 如CRC 校驗算法, 挖掘其背后的并行性對提升程序性能意義重大. 對Scramble 和Generate PRS 模塊可進行位運算并行化優化, 下面以Generate PRS 為例說明. 優化前代碼如代碼2 所示.

代碼2. GeneratePRS 位運算部分代碼// Generate c for i:= 0 to len step 1 do //x1, x2 分別進行低3 位異或, 有效結果為最后一個bit new_bitl := ((xl >> 3) ^ xl) & 0xl new_bit2 := ((x2 >> 3) ^ (x2 >> 2) ^ (x2 >> 1) ^ x2) & 0xl //x1, x2 分別進行最高位數值更新 xl := (xl >> 1) | (new_bitl << 30) x2 := (x2 >> 1) | (new_bit2 << 30) c[i] := new_bitl ^ new_bit2

這個模塊主要以移位和異或操作為主. 要對這部分操作進行并行優化, 需要解決兩個問題: (1) 解決數據依賴. 存在數據依賴意味著每次迭代操作必須串行進行, 需要消除依賴, 實現并行操作; (2) 逐位異或操作.一般的異或操作主要是針對兩個獨立的變量的, 需實現位間高效位運算的方法.

優化分析: (1) 數據依賴. 真依賴主要存在于x1/x2兩個變量, 但進一步分析發現, 前一次迭代寫的是x2的最高位, 而后一次則讀的是最后4 位, 實際上并不是真依賴. 本文針對讀寫部分, 分別做并行化. (2) 一個數字內部逐位的異或操作, 采用數字移位并且對應位異或的方式實現. 優化后的代碼如代碼3 所示. 由于函數返回的結果是res每一個位上的值, 所以需要把res逐位右移以取得最終結果.

代碼3. Generate 消除數據依賴及并行化代碼// Generate c for i := 0 to col step 28 do //一次循環計算28 個有效bit 數據, 先計算x1 x13 := xl >> 3 tmpl := xl3 ^ xl //此處和0X7FFFFFFF 做 “與”操作, 而不是0x1 xl := (tmpl << 3 | xl >> 28) & 0X7FFFFFFF //計算x2 x21 := x2 >> 1 x22 := x2 >> 2 x23 := x2 >> 3 tmp2 := x2 ^ x21 ^ x22 ^ x23 x2 := (tmp2 << 3 | x2 >> 28) & 0X7FFFFFFF res := tmpl ^ tmp2 //逐bit 給C 數組賦值 for j := i to (28 + i) step 1 do c[j] := (res >> j-i) & 0x1

該模塊基本都是位運算操作, 指令數直接決定了執行時間, 優化之后指令數變為原來的1/2, 性能加速比為2.45 倍.

1.3.3 分支歸零化

分支語句會帶來嚴重的性能問題. 當前CPU 都有分支預測單元, 如果預測正確, 則條件語句只花費一個CPU 周期, 而如果預測錯誤, 將可能花費幾十個或更多CPU 周期. 所以, 盡可能減少分支語句, 可以加速程序的執行時間. 本文對Rate Match 和Modulation 模塊進行了分支優化, 以下詳細介紹Modulation 優化方法,代碼見代碼4.

代碼4. Modulation 64 種情況的 switch 語句for i := 0 to N_bits step 1 do

? switch bits[i] of case 0: d_re[i] = +3 * 42 d_im[i] = +3 * 42 break case 1: d_re[i] = +3 * 42 d_im[i] = +1 * 42 break … //省略case2, …, case63 的代碼, 均與case1 類似 case 63: d_re[i] = ?7 images/BZ_63_1524_1063_1527_1064.png* 42 d_im[i] = ?7 * 42 break

圖中switch 語句處于循環體的內部, 但不能簡單地將分支語句提出循環外, 原因在于: (1) 條件判斷變量與迭代變量密切相關; (2) 條件判斷的計算結果完全是隨機的, 分支預測失敗的可能性很高. 所以這部分語句很耗時, 本文采用了查表法來代替分支選擇, 將每一條分支語句都轉化成查表語句.

優化分析: 該部分代碼中有64 個case, 但經分析發現, 雖然case 數目眾多, 但是每個case 內都進行的是賦值操作, 并且都是用同樣的常數賦值, 只有符號位和系數不同, 所以采用查表法進行優化.

優化后代碼如代碼5 所示. 將每個case 的系數和符號分別實現為系數索引表和符號索引表, switch 部分的判斷操作單獨計算, 用計算值作為key 索引賦值常數的系數和符號表. 經過優化完全消除了switch 語句, 實測執行時間加速比2.39 倍.

代碼5. Modulation 查表操作優化代碼Create symbol array sym_re[0..63] and sym_im[0..63]Create coefficient array con_re[0..63] and con_im[0..63]for i := 0 to N_bits step 1 do //按照索引值, 從符號表和系數表取對應數值 index := bits[i] d_re[i] := sym_re[k] * con_re[k] * 42 d_im[i] := sym_im[k] * con_im[k] * 42

1.3.4 特征提取優化

除了廣為人知的一些優化手段外, 還可以結合程序的具體特征來做優化. Rate Match 模塊優化前執行時間占到總時間的60%. 其性能瓶頸在于: 賦值操作,每次賦值之前都有一個條件判斷, 且判斷條件與迭代變量相關, 該賦值部分代碼如代碼6 所示.

代碼6. Rate Match 耗時長語句while k < N_e_bits do if(rmt_w[(k_0 + j) % N_cb] != TX_NULL_BIT) then e_bits[k++] := rmt_w[(k_0 + j) % N_cb] j:= j+1

優化分析: 在該段循環每執行一次賦值操作, 就要做一次if 分支判斷, 判斷rmt_w的值是否為TX_NULL_BIT. 進一步對rmt_w數組進行分析發現, 該數組中最多有31 個值為TX_NULL_BIT, 而整個數組的長度為將近7 萬, 所以特殊值的比例極小, 對每個數都檢查一遍開銷很大. 所以本文提出先并行賦值32 個數, 然后對這32 個數統一進行特殊值檢查, 如果包含特殊值,再逐個進行賦值, 否則, 就賦值成功. 優化后的代碼如代碼7 所示.

代碼7. Rate Match 按照數據分布特征優化后代碼//申請256 字節空間, 初始化為特殊值mask := _mm256_setl_epi8(100)while N_e_bits > 32 do //先一次并行拷貝32 個數據 src := _mm256_loadu_si256((__m256i*) & (rmt_w[(k_0 + j) %N_cb])) //再檢查是否存在特殊值 res := _mm256_testz_si256(mask, src) //如果不存在特殊值 if(res == 1) then //并行賦值32 個數 _mm256_storeu_si256((__m256i *) & (e_bits[k]), src) k := k+32; N_e_bits -=32 else //如果存在特殊值, 逐個檢查并拷貝 for i := 0 to 32 step 1 do if(rmt_w[(k_0 + j) % N_cb] != TX_NULL_BIT) then e_bits[k++] := rmt_w[(k_0 + j) % N_cb] j += 32//剩余不足32 個數的部分, 按照原方式拷貝

該部分優化采用并行賦值操作, 有效減少分支語句, 實際執行指令數大幅減少, 為原來的1/12, 實際執行時間加速比為14 倍.

1.3.5 延遲加速化

Rate Match 的另一個性能瓶頸是高延遲操作, 該模塊中出現了除法和取模操作(取模操作用到除法部件), 本實驗機器平臺除法指令延遲為89 個時鐘周期,而普通的加、減和位運算指令都是1 個時鐘周期[20],所以非常耗時. 該部分源代碼如代碼8 所示.

代碼8. Rate Match 取模和除法操作代碼?

K pi := R tc sb * C tc sb for i := 0 to K_pi step 1 do pi_idx := (IC_PERM_TC[i / R_tc_sb] + C_tc_sb * (i % R_tc_sb) + 1)% K_pi rmt_w[K_pi + (2 * w_idx) + 1] := rmt_y[pi_idx]?

優化分析: 在上述代碼中有兩處取模操作, 一次除法操作. (1) 第2 個取模操作只發生迭代變量達到最大的時候, 也就是只有一次計算有用, 所以可以分成0–(K_pi–1), 和K_pi兩種情況. 前一種情況完全省去了取模操作; (2) 除法操作和第1 個取模操作. 可以用兩層循環來代替, 內層循環的上界為R_tc_sb, 內層迭代變量j表示i%R_tc_sb, 外層循環的上界為K_pi/R_tc_sb–1, 外層迭代變量k表示i/R_tc_sb. 這樣剩下R_tc_sb個數據尚未處理, 再分成兩種情況: (1) 0 到(R_tc_sb–1)個數, 可以省去除法和取模操作; (2) 最后一個數, 也是i等于K_pi時, 直接將index為0 時的值作為源數據拷貝. 優化后的代碼如代碼9 所示. 該優化有效去除了除法操作和取模操作, 實測取得了8 倍性能加速比.

代碼9. 消除取模操作后兩層循環代碼K pi := R tc sb * C tc sb//取模和除法操作分別由內外層循環變量替代for j:=0 to (C_tc_sb-2) step 1 do for i:=0 to (R_tc_sb-2) step 1 do pi_idx := IC_PERM_TC[j] + C_tc_sb*i + 1 rmt_w[K_pi + (2 * w_idx) + 1] := rmt_y[pi_idx] w_idx ++//處理外層循環變量的邊界值j := C_tc_sb-1 for i:=0 to (R_tc_sb-2) step 1 do pi_idx := IC_PERM_TC[j] + C_tc_sb*i + 1 rmt_w[K_pi + (2 * w_idx) + 1] := rmt_y[pi_idx] w_idx ++//處理內外層循環迭代變量的邊界值rmt_w[K_pi + (2 * w_idx) + 1] := rmt_y[0]

1.4 OpenLTE 優化效果評估

本文對OpenLTE 物理層下行過程從TB-CRC 到IFFT 的10 個模塊逐個進行優化, 最終整個下行過程取得2.5 倍加速比, 模塊整體最好取得12.5 倍加速比, 被優化部分最好取得26 倍加速比, 數據如表1 所示.

表1 OpenLTE 下行過程各模塊優化效果總結

2 5G 應用行為分析

由于通用處理器處理能力的快速發展, 5G 應用由專用處理器轉移到通用處理器上. 本文將研究通用處理器上獨特的參數, 如多核、SMT 和Turbo Boost[21]等對應用產生的影響. 通過本文前期實驗驗證, 當5G應用與其他負載混合執行時, 性能會受到不同程度的影響, 所以本文只研究5G 應用自身多線程部署時的行為.

2.1 實驗平臺

本文選用的實驗機器配置如表2 所示, 測試對象為優化后的OpenLTE 程序下行過程. 實驗過程將關注該過程中每個模塊(函數)的處理時間以及整個應用的執行時間.

表2 機器參數描述 (E5-2620)

2.2 共享緩存和訪存帶寬競爭分析

[SMT = OFF, Turbo Boost = OFF] 本文將通過改變并發線程數的方式來研究應用對共享緩存和訪存帶寬的競爭情況. 因為處理器支持SMT, 所以為了避免SMT 對結果的影響, 本文只在一個核上部署一個線程;同樣為排除Turbo Boost 對程序性能的影響, 關閉Turbo Boost.

在該場景中, 單個線程可以完成5G 應用下行過程物理層的所有處理過程, 增加線程數是提升了系統的整體并發量, 而不是將單個任務拆分為多個可并發的子任務, 該實驗的目的是分析多個并發的獨自處理過程之間的性能干擾情況.

如圖2 所示, 橫軸表示下行過程中的不同模塊, 縱軸表示執行時間. 圖中每個模塊從左到右分別表示并發線程數從1 到6. 可以看到線程的并發量逐漸增長到與核數相同, 單個線程的執行時間保持不變.

圖2 不同線程并發量時各模塊執行時間

本文進一步測量程序在共享緩存的失效率和訪存帶寬的需求情況. 如圖3 所示, 隨著在同一個CPU 上并發的線程數不斷增多, 總訪存帶寬逐漸增多, 但是最多到0.3 GB/s, 而本實驗機器的訪存峰值帶寬為21.3 GB/s,可見不同線程之間對訪存帶寬的競爭很不激烈. 并且共享緩存的失效率一直很低并且基本不變, 說明應用對共享緩存的需求很小, 即使存在多個線程, 彼此也不會爭搶共享緩存.

圖3 不同并發線程數總訪存指標的變化

總結: 該應用的每個線程對共享緩存的需求較小,訪存量很少, 不是訪存密集型的應用.

2.3 計算部件和私有緩存競爭分析

[SMT = ON, Turbo Boost = OFF] 本節將討論由單個處理器核心支持的多線程對核內共享資源的競爭情況. 本文將對比采用SMT 技術和不采用SMT 技術的實驗結果, 由于本文的研究關注點在一個核心內部的資源, 所以只在一個處理器核心活躍的情況下實驗, 為避免Turbo Boost 帶來的干擾, 同樣會關閉Turbo Boost.不采用SMT 的方式, 是兩個線程分別運行在兩個不同的物理核上, 稱為Mapping 1; 采用SMT 的方式, 是兩個線程都運行在同一個物理核心上, 稱為Mapping 2.

如圖4, 藍色的柱子表示一個物理核運行一個線程, 紅色柱子表示一個物理核運行兩個線程, 可以明顯發現當兩個線程同時運行在一個物理核上時, 單個線程的執行時間明顯變長, 整個過程執行時間平均增加60%, Scramble 模塊執行時間增加了一倍, 5G 應用的SMT 線程之間存在明顯的性能干擾.

圖4 SMT 部署對單線程執行時間的影響

接下來將介紹性能干擾的原因. 測量5G 應用在執行部件上的行為, 需要測量線程總執行周期數和處于阻塞狀態的時鐘周期數, 這兩個指標可以反映程序執行期間執行部件的繁忙程度, 若處于阻塞狀態所占時鐘周期數多, 則代表程序大部分時間都在等待. 本文對單線程和SMT 情況下分別統計UOPS_RETIRED.TOTAL_CYCLES/UOPS_RETIRED.STALL_CYCLES,

這兩個指標分別表示該進程的微指令無論處于阻塞或者執行狀態的所有的時鐘周期即進程的總時鐘周期數,后一個指標表示微指令處于阻塞狀態的時鐘周期數.

如圖5 所示, 只有單線程執行時, 處于阻塞狀態的時鐘周期數占到總的時鐘周期數的20%, 表明5G 應用是計算較密集的應用. 當采用SMT 時, 整個應用的時鐘周期數明顯增加, 對比兩個柱子可以看到, 執行時間并未有變化, 增加的時鐘周期數全部來源于阻塞時鐘周期數. 指令被阻塞可能的原因是來自于執行部件的競爭, 或者等待來自于緩存的數據. 所以本文將SMT狀態下的阻塞時鐘周期數做了進一步分析, 發現分為四部分: 來自于單線程執行狀態下已有的阻塞、由于等待L1 緩存中的數據造成的阻塞、由于等待L2 緩存中的數據造成的阻塞以及由于另一個線程占據執行部件而造成的阻塞, 而大部分阻塞都是由于等待另一個線程釋放執行部件造成的, 證明5G 應用SMT 線程間對執行部件的競爭激烈.

圖5 采用SMT 部署執行和阻塞部分時鐘周期數

上述實驗本文論證了5G 應用在采用SMT 方式帶來的負面作用, 接下來將從處理器資源利用率的角度來說明SMT 的好處.

本文從執行部件的利用率和吞吐量兩個角度來說明. 如圖6 所示, 在本實驗機型中, 端口0、1 和5 表示ALU等計算部件, 而端口2、3 和4 則表示訪存部件, 對于5G 應用, 計算部件的利用率明顯高于訪存部件, 再次說明這是計算密集型應用, 而藍色柱子表示單線程執行時的部件利用率, 而紅色柱子表示SMT 線程執行時的部件利用率, 采用SMT 之后, 各部件的利用率都提升.

圖6 采用SMT 部署各部件的利用率

如圖7 所示, 藍色表示單線程執行時, 大部分都是每個時鐘周期執行1 條或2 條微指令, 而紅色采用SMT 之后, 每個時鐘周期能同時執行3 條或者4 條微指令的比例大幅增加, 大多數時鐘周期都能執行1、2 或3 條微指令, 提升了處理器的吞吐量.

圖7 采用SMT 部署吞吐量的變化

總結: 5G 應用計算很密集, 執行部件的利用率較高, 不采用SMT 方式時, 5G 應用可以占滿所有處理器核心; 采用SMT 方式時, 線程之間性能干擾嚴重.

2.4 Turbo Boost 影響分析

[SMT = OFF, Turbo Boost = ON] 本節將討論即使不存在資源競爭時, 處理器本身的特性——超頻, 對應用并發執行時的性能影響, 并且SMT 將關閉. 超頻對處理器主頻的影響如表3 所示.

表3 Turbo Boost 頻率變化

如圖8, 應用執行時并發的線程數量從1 增加到6,1 或2 個線程并發執行時, 每個線程的執行時間最少;3 或4 個線程并發執行時, 每個線程的執行時間增加5%; 5 或6 個線程并發執行時, 每個線程的執行時間相比單線程執行時增加10%. 所以, 雖然線程間對共享資源的競爭不激烈, 由于超頻的作用, 當活躍處理器核心數增多, 每個線程的響應時間增加了.

圖8 開啟Turbo Boost 時, 單線程執行時間隨活躍處理器核心數目變化的規律

本文把打開超頻和不打開超頻的結果做個對比,如圖9, 前3 種顏色的柱子表示打開超頻, 并行活躍的處理器核心數為1、3 和5 三種情況, 后一種顏色的柱子表示關閉Turbo Boost 的結果, 可以看到關閉Turbo Boost 之后, 執行時間明顯大幅增加, 約增加20%.

圖9 Turbo Boost 對性能的影響程度

結論. 超頻可以顯著提升應用的性能, 但是同時需要注意的問題是, 實際軟件開發過程中, 往往測試應用的響應時間會從單線程開始, 在對應用和設備足夠了解的情況下, 即使能斷定多線程執行時, 并發體之間不會由于資源競爭產生性能干擾, 但由于Turbo Boost 的影響, 多線程執行時, 每個線程響應時間也會有一定增加, 所以對單線程性能基準的評定應提高要求, 這樣才能保證應用在多線程并發時, 仍然滿足性能要求.

2.5 5G 應用在數據中心部署建議

通過對5G 應用下行過程物理層全面的分析評估,對應用自身特性和并發執行的行為得出的結論如下:

(1) 應用特性. 5G 應用下行過程物理層數據解析過程是計算密集型的, 對于共享緩存的壓力較小, 實際占用的訪存帶寬也很小, 對響應時間要求極高, 處于微妙級.

(2) 混合執行行為及部署建議. 1)不采用SMT, 由于該應用是計算密集型的, 執行部件的利用率已經很高, 兩個線程同時執行時, 單個線程被阻塞的時間增加,性能下降了. 2)線程并發量. 多核多線程執行時對共享資源競爭不激烈, 但是同一個核心多線程之間由于競爭執行部件性能干擾嚴重, 所以在不超過核數時盡量可以多部署線程. 3) Turbo Boost, 可以選擇打開或不打開, 各有利弊. 打開Turbo Boost 時, 程序的性能相對較好, 但是性能會隨著活躍處理器核心數目變化而不穩定, 影響單線程性評測時的基準的設定. 不打開Turbo Boost 時, 性能不會隨著活躍處理器核心數變化而抖動, 但是整體性能一般.

3 結束語

本文結合體系結構特征分析5G 應用執行行為, 發現5G 應用下行過程的物理層處理流程是計算密集型的, 最高端口利用率90%, 然后分析應用并發行為, 最后以性能最佳化為目的給出5G 應用在數據中心部署建議, 應用對實時性要求極其嚴格, 只能應用獨占機器執行; 計算工作集小, 對內存及其子系統壓力小, 不超過處理器物理核數的情況下可以盡可能多部署線程;SMT 會造成響應時間增加60%, 嚴重影響性能因此不宜采用. 本文還針對開源實現的OpenLTE 代碼進行面向通用處理器特征的優化, 設計并實現了訪存并行化、位操作并行化、分支歸零化、特征提取優化和延遲加速化等優化方式, 整體優化后加速比為2.5 倍, 單個優化基本塊取得最好性能加速比為26 倍. 本文僅針對5G應用下行過程的物理層進行特征刻畫, 還不能夠全面評估應用整體的行為, 后續將會繼續對物理層上行鏈路進行分析, 從而更加準確分析應用在數據中心的行為, 以達到資源的合理部署, 提升數據中心資源利用率.