宋老師的SMT測試很有意思,但是編譯內核涉及的因素太多了,包括訪問文件系統等耗時受到存儲器性能的影響,難以估算,因此很難評判SMT對性能的提升如何。
為了探究SMT對計算密集型workload的效果,我自己寫了一個簡單的測試程序。
使用pthread開多個線程,每個線程分別計算斐波那契數列第N號元素的值。每個線程計算斐波那契數列時除線程的元數據外只分配兩個unsigned long變量,由此避免過高的內存開銷。
workload的詳細代碼和測試腳本在[https://github.com/HongweiQin/smt_test]
毫無疑問,這是一個計算密集型負載,我在自己的筆記本上運行,配置如下(省略了一些不重要的項目):
lscpu
Architecture: x86_64
12 :
CPU(s) list: 0-11
per core: 2
per socket: 6
1 :
NUMA node(s): 1
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
L1d cache: 192 KiB
L1i cache: 192 KiB
L2 cache: 1.5 MiB
L3 cache: 12 MiB
可以看到筆記本有一個Intel i7的處理器,6核12線程。經查,CPU0和CPU6共用一個Core,CPU1和CPU7共用一個Core,以此類推。
以下的測試(Test 1-5)中,每個線程分別計算斐波那契數列第40億號元素的數值。
Test1:采用默認配置,開12線程進行測試。測試結果為總耗時45.003s。
qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000
threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32
real0m45.003s
user7m12.953s
sys0m0.485s
Test2:把smt關掉,同樣的測試方法(12線程)。總耗時為25.733s。
qhw@qhw-laptop:~/develop/smt_test$ cat turnoff_smt.sh
echo "turn off smt"
sudo sh -c 'echo off > /sys/devices/system/cpu/smt/control'
qhw@qhw-laptop:~/develop/smt_test$ ./turnoff_smt.sh
turn off smt
qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000
threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32
real0m25.733s
user2m23.525s
sys0m0.116s
對,你沒看錯。同樣的workload,如果關掉smt,總耗時還變少了。Intel誠不欺我!
Test3:再次允許smt,但是將程序限制在三個物理Core上運行,則總耗時為34.896s。
qhw@qhw-laptop:~/develop/smt_test$ ./turnon_smt.sh
turn on smt
qhw@qhw-laptop:~/develop/smt_test$ time taskset -c 0-2,6-8 ./smt_test -f 4000000000
threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32
real0m34.896s
user3m17.033s
sys0m0.028s
Test3相比于Test1用了更少的Core,反而更快了。
為什么在Test2和3會出現這樣違反直覺的結果?
猜想:Cache一致性在作怪!
圖1
測試程序的main函數會分配一個含有T(T=nr_threads)個元素的`struct thread_info`類型的數組,并分別將每個元素作為參數傳遞給每個計算線程使用。`struct thread_info`定義如下:
struct thread_info {
pthread_t thread_id;
int thread_num;
unsigned long res[2];
};
結構體中的res數組用于計算斐波那契數列,因此會被工作線程頻繁地寫。
注意到,sizeof(struct thread_info)為32,而我的CPU的cacheline大小為64B!這意味著什么?
如果Thread 0在Core 0上運行,則它會頻繁寫tinfo[0],Thread 1在Core 1上運行,則它會頻繁寫tinfo[1]。
這意味著,當Thread 0寫tinfo[0]時,它其實是寫入了Core 0上L1 Cache的Cacheline。同樣的,當Thread 1寫tinfo[1]時,它其實是寫入了Core 1上L1 Cache的Cacheline。此時,由于Core 1上的Cacheline并非最新,因此CPU需要首先將Core 0中的Cacheline寫入多核共享的L3 Cache甚至是內存中,然后再將其讀入Core 1的L1 Cache中,最后再將Thread 1的數據寫入。此時,由于Cache 0中的數據并非最新,Cacheline會被無效化。由此可見,如果程序一直這樣運行下去,這一組數據需要在Cache 0和1之間反復跳躍,占用較多時間。
這個猜想同樣可以解釋為什么使用較少的CPU可以加速程序運行。原因是當使用較少的CPU時,多線程不得不分時共用CPU,如果Thread 0和Thread 1分時共用了同一個CPU,則不需要頻繁將Cache無效化,程序運行時間也就縮短了。
驗證猜想:增加內存分配粒度!
對程序進行修改后,可以使用`-g alloc_granularity`參數設定tinfo結構體的分配粒度。使用4KB為粒度進行分配,再次進行測試:
Test4:12線程,開啟SMT,分配粒度為4096。總耗時為13.193s,性能相比于Test1的45.003s有了質的提升!
qhw@qhw-laptop:~/develop/smt_test$ time ./smt_test -f 4000000000 -g 4096
threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096
real0m13.193s
user2m31.091s
sys0m0.217s
Test5:在Test4的基礎上限制只能使用3個物理Core。總耗時為24.841s,基本上是Test4的兩倍。這說明在這個測試下,多核性能還是線性可擴展的。
qhw@qhw-laptop:~/develop/smt_test$ time taskset -c 0-2,6-8 ./smt_test -f 4000000000 -g 4096
threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096
real0m24.841s
user2m26.253s
sys0m0.032s
超線程SMT究竟可以快多少?
表格和結論:
測試名 | 硬件配置 | 運行時間(s) |
Test6 | “真”6核 | 38.562 |
Test7 | “假”6核 | 58.843 |
Test8 | “真”3核 | 73.175 |
測試使用的是6個工作線程。為了減少誤差,增加一點運行時間,每個線程計算斐波那契數列第200億項的值。
對比Test6和7,可以看到SMT的提升大概在52.6%左右。
測試記錄:
Test6:別名“真”6核,使用6個關閉了SMT的物理核進行計算。總耗時為38.562s。
Test7:別名“假”6核,使用3個開啟了SMT的物理核進行計算。總耗時為58.843s。
Test8:別名“真”3核,使用3個關閉了SMT的物理核進行計算。總耗時為1m13.175s。
qhw@qhw-laptop:~/develop/smt_test$ cat test.sh
fibonacci=20000000000
sudo printf ""
./turnoff_smt.sh
time ./smt_test -f $fibonacci -g 4096 -t 6
./turnon_smt.sh
time taskset -c 0-2,6-8 ./smt_test -f $fibonacci -g 4096 -t 6
./turnoff_smt.sh
time taskset -c 0-2,6-8 ./smt_test -f $fibonacci -g 4096 -t 6
./turnon_smt.sh
qhw@qhw-laptop:~/develop/smt_test$ ./test.sh
turn off smt
threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096
real0m38.562s
user3m50.786s
sys0m0.000s
turn on smt
threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096
real0m58.843s
user5m53.018s
sys0m0.005s
turn off smt
threads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096
real1m13.175s
user3m39.486s
sys0m0.008s
turn on smt
責任編輯:haq
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。
舉報投訴
-
smt
+關注
關注
40文章
2907瀏覽量
69363 -
多線程
+關注
關注
0文章
278瀏覽量
20014
原文標題:超線程SMT究竟可以快多少?(斐波那契版)
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
人員定位系統對生產密集型企業的重要意義
發電、供電、石油化工、鋼鐵冶金行業為生產設備密集型企業,生產現場錯綜復雜,稍有不慎便會發生危險;建筑工地現場施工作業中,存在著人員流動性大、現場狀況雜亂、安全隱患難以察覺等問題;工廠安全管理混亂
廣和通端側AI解決方案驅動性能密集型場景商用型場景商用
2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側AI解決方案高效使能性能密集型場景。該端側AI解決方案整合強大AI算力、邊緣側AI數據分析及Wi-Fi 7連接方式,可為自主移動機器人、工業無人機、云服務器和AI邊緣計算盒子等物聯網應用提供端側
廣和通端側AI解決方案驅動性能密集型場景商用型場景商用
2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側AI解決方案高效使能性能密集型場景。該端側AI解決方案整合強大AI算力、邊緣側AI數據分析及Wi-Fi 7連接方式,可為自主移動機器人、工業無人機、云服務器和AI邊緣計算盒子等物聯網應用提供端側
鴻蒙OS開發實例:【ArkTS類庫多線程CPU密集型任務TaskPool】
CPU密集型任務是指需要占用系統資源處理大量計算能力的任務,需要長時間運行,這段時間會阻塞線程其它事件的處理,不適宜放在主線程進行。例如圖像處理、視頻編碼、數據分析等。
基于多線程并發機制處理CPU密集型任務可以提高CPU
鴻蒙OS開發實例:【ArkTS類庫多線程I/O密集型任務開發】
使用異步并發可以解決單次I/O任務阻塞的問題,但是如果遇到I/O密集型任務,同樣會阻塞線程中其它任務的執行,這時需要使用多線程并發能力來進行解決。
I/O密集型任務的性能重點通常不在于CPU
博泰“車聯網云服務平臺”入選2023年度專利密集型產品名單
近日,中國專利保護協會首次組織開展了專利密集型產品認定工作,并于近期發布2023年專利密集型產品名單,博泰的“車聯網云服務平臺”入選2023年度專利密集型產品名單。
博泰車聯網云服務平臺入選2023年度專利密集型產品名單
近日,中國專利保護協會公布了2023年專利密集型產品名單,博泰車聯網的“車聯網云服務平臺”憑借其卓越的技術創新和專利布局,成功入選該名單。這一榮譽不僅彰顯了博泰在車聯網領域的領先地位,也體現了其對知識產權保護的重視和貢獻。
鴻蒙原生應用開發-ArkTS語言基礎類庫多線程I/O密集型任務開發
使用異步并發可以解決單次I/O任務阻塞的問題,但是如果遇到I/O密集型任務,同樣會阻塞線程中其它任務的執行,這時需要使用多線程并發能力來進行解決。
I/O密集型任務的性能重點通常不在于CPU的處理
發表于 03-21 14:57
鴻蒙原生應用開發-ArkTS語言基礎類庫多線程CPU密集型任務TaskPool
CPU密集型任務是指需要占用系統資源處理大量計算能力的任務,需要長時間運行,這段時間會阻塞線程其它事件的處理,不適宜放在主線程進行。例如圖像處理、視頻編碼、數據分析等。
基于多線程并發機制處理CPU
發表于 03-19 14:14
山東外貿進出口總額同比增長3.6%,機電、勞動密集型產品和農產品出口增長
2024年度前兩個月,山東省進出口業務中有一個值得關注的亮點:各項商品的出口量及進口量均呈現正向增長。具體來看,機電產品、勞動密集型產品以及農產品的出口特別強勁,其中尤其是機電產品
什么是FPGA?帶你初步揭開它的面紗
計算密集型任務,如矩陣運算、圖像處理、機器學習等。與CPU相比,FPGA在這些任務上具有更高的性能和更低的延遲。 此外,FPGA在通信密集型任務中也具有顯著優勢。由于FPGA上的收發器可以直接
發表于 02-21 16:10
HarmonyOS CPU與I/O密集型任務開發指導
一、CPU密集型任務開發指導 CPU密集型任務是指需要占用系統資源處理大量計算能力的任務,需要長時間運行,這段時間會阻塞線程其它事件的處理,不適宜放在主線程進行。例如圖像處理、視頻編碼、數據分析等
評論