宋老師的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
+關注
關注
42文章
3012瀏覽量
71196 -
多線程
+關注
關注
0文章
279瀏覽量
20284
原文標題:超線程SMT究竟可以快多少?(斐波那契版)
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
熱點推薦
告別性能瓶頸:使用 Google Coral TPU 為樹莓派注入強大AI計算力!
使用機器學習的應用程序通常需要高計算能力。這些計算通常發生在顯卡的GPU上。RaspberryPi并不專門設計用于運行計算密集型應用程序。但GoogleCoralUSB加速器能在此提供

請問如何在Python中實現多線程與多進程的協作?
大家好!我最近在開發一個Python項目時,需要同時處理多個任務,且每個任務需要不同的計算資源。我想通過多線程和多進程的組合來實現并發,但遇到了一些問題。
具體來說,我有兩個任務,一個是I/O密集型
發表于 03-11 06:57
金倉數據庫入選《2024年度專利密集型產品名單》
2月8日, 國家專利密集型產品備案認定試點平臺公布了《2024年度專利密集型產品名單》,由電科金倉自主研發的金倉數據庫管理系統(KingbaseES)憑借扎實的技術積淀與市場驗證,成功入選該名

L-com諾通推出新型6類屏蔽型超薄以太網線纜
密集型布線對線纜要求更高,L-com諾通為了更好完善客戶高密度布線應用,推出了新型6類屏蔽型超薄以太網線纜。
揭秘SMT貼片加工價格計算:全方位解析成本構成
一站式PCBA智造廠家今天為大家講講SMT貼片加工廠價格計算方法有哪些?SMT貼片加工廠價格計算方法。在電子制造行業,SMT貼片加工是PCB
FP8在大模型訓練中的應用
越來越多的技術團隊開始使用 FP8 進行大模型訓練,這主要因為 FP8 有很多技術優勢。比如在新一代的 GPU 上,FP8 相對于 BF16 對矩陣乘算子這樣的計算密集型算子,NVIDIA

SMT產線固定讀碼器的應用效果
在當今高度自動化的制造業中,SMT(表面貼裝技術)產線作為電子組裝的核心環節,其效率與精度直接影響著產品的質量與成本。而SMT產線固定讀碼器的應用,無疑是這一領域內的一次重要技術革新,為生產流程帶來

使用 AMD Versal AI 引擎釋放 DSP 計算的潛力
的 DSP 應用。 AMD Versal AI 引擎使您能夠擴展數字信號處理 (DSP) 計算和面向未來的設計,以適應當前和下一代計算密集型 DSP 應用。借助 Versal AI 引擎,客戶可以期望以
AMD Alveo V80計算加速器網絡研討會
歡迎參加本次網絡研討會,我們將深入探討 AMD Alveo V80 計算加速器如何幫助您處理高性能計算、數據分析、金融科技、網絡安全、存儲加速、AI 計算等領域的內存密集型工作負載。A
AMD推出EPYC Embedded霄龍嵌入式8004系列處理器
AMD近日正式推出了全新的EPYC Embedded霄龍8004系列處理器,為計算密集型嵌入式系統帶來了更加強勁的性能。
人員定位系統對生產密集型企業的重要意義
發電、供電、石油化工、鋼鐵冶金行業為生產設備密集型企業,生產現場錯綜復雜,稍有不慎便會發生危險;建筑工地現場施工作業中,存在著人員流動性大、現場狀況雜亂、安全隱患難以察覺等問題;工廠安全管理混亂

廣和通端側AI解決方案驅動性能密集型場景商用型場景商用
2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側AI解決方案高效使能性能密集型場景。該端側AI解決方案整合強大AI算力、邊緣側AI數據分析及Wi-Fi 7連接方式,可為自主移動機器人、工業無人機、云服務器和AI邊緣計算盒子等物聯網應用提供端側
廣和通端側AI解決方案驅動性能密集型場景商用型場景商用
2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側AI解決方案高效使能性能密集型場景。該端側AI解決方案整合強大AI算力、邊緣側AI數據分析及Wi-Fi 7連接方式,可為自主移動機器人、工業無人機、云服務器和AI邊緣計算盒子等物聯網應用提供端側

商湯科技助力碳密集型企業實現綠色轉型
隨著生成式AI技術飛速演進,算力中心迎來規模化發展,算力與電力正在形成相互支撐、協同發展的新態勢。一方面,算力中心的高效運轉離不開大量電力支撐;另一方面,電力系統的平穩高效運行也離不開算力支撐。 商湯基于自身實踐,形成了一套覆蓋基礎設施層、機柜層、GPU服務器層、軟件管理層和業務運營側的“算電一體化協同”算效管理方案,有效打通了從硬件到軟件、從電力到算力的應用場景,為算力高效輸出提供有效依據。 基于多層管理措
評論