為了探究SMT對計算密集型workload的效果,我自己寫了一個簡單的測試程序。
使用pthread開多個線程,每個線程分別計算斐波那契數(shù)列第N號元素的值。每個線程計算斐波那契數(shù)列時除線程的元數(shù)據(jù)外只分配兩個unsigned long變量,由此避免過高的內(nèi)存開銷。
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線程。經(jīng)查,CPU0和CPU6共用一個Core,CPU1和CPU7共用一個Core,以此類推。
以下的測試(Test 1-5)中,每個線程分別計算斐波那契數(shù)列第40億號元素的數(shù)值。
Test1:采用默認配置,開12線程進行測試。測試結(jié)果為總耗時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關(guān)掉,同樣的測試方法(12線程)??偤臅r為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,如果關(guān)掉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會出現(xiàn)這樣違反直覺的結(jié)果?
猜想:Cache一致性在作怪!

圖1
測試程序的main函數(shù)會分配一個含有T(T=nr_threads)個元素的`struct thread_info`類型的數(shù)組,并分別將每個元素作為參數(shù)傳遞給每個計算線程使用。`struct thread_info`定義如下:
struct thread_info {
pthread_t thread_id;
int thread_num;
unsigned long res[2];
};
結(jié)構(gòu)體中的res數(shù)組用于計算斐波那契數(shù)列,因此會被工作線程頻繁地寫。
注意到,sizeof(struct thread_info)為32,而我的CPU的cacheline大小為64B!這意味著什么?
如果Thread 0在Core 0上運行,則它會頻繁寫tinfo[0],Thread 1在Core 1上運行,則它會頻繁寫tinfo[1]。
這意味著,當(dāng)Thread 0寫tinfo[0]時,它其實是寫入了Core 0上L1 Cache的Cacheline。同樣的,當(dāng)Thread 1寫tinfo[1]時,它其實是寫入了Core 1上L1 Cache的Cacheline。此時,由于Core 1上的Cacheline并非最新,因此CPU需要首先將Core 0中的Cacheline寫入多核共享的L3 Cache甚至是內(nèi)存中,然后再將其讀入Core 1的L1 Cache中,最后再將Thread 1的數(shù)據(jù)寫入。此時,由于Cache 0中的數(shù)據(jù)并非最新,Cacheline會被無效化。由此可見,如果程序一直這樣運行下去,這一組數(shù)據(jù)需要在Cache 0和1之間反復(fù)跳躍,占用較多時間。
這個猜想同樣可以解釋為什么使用較少的CPU可以加速程序運行。原因是當(dāng)使用較少的CPU時,多線程不得不分時共用CPU,如果Thread 0和Thread 1分時共用了同一個CPU,則不需要頻繁將Cache無效化,程序運行時間也就縮短了。
驗證猜想:增加內(nèi)存分配粒度!
對程序進行修改后,可以使用`-g alloc_granularity`參數(shù)設(shè)定tinfo結(jié)構(gòu)體的分配粒度。使用4KB為粒度進行分配,再次進行測試:
Test4:12線程,開啟SMT,分配粒度為4096??偤臅r為13.193s,性能相比于Test1的45.003s有了質(zhì)的提升!
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的基礎(chǔ)上限制只能使用3個物理Core??偤臅r為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究竟可以快多少?
表格和結(jié)論:
測試名 | 硬件配置 | 運行時間(s) |
Test6 | “真”6核 | 38.562 |
Test7 | “假”6核 | 58.843 |
Test8 | “真”3核 | 73.175 |
測試使用的是6個工作線程。為了減少誤差,增加一點運行時間,每個線程計算斐波那契數(shù)列第200億項的值。
對比Test6和7,可以看到SMT的提升大概在52.6%左右。
測試記錄:
Test6:別名“真”6核,使用6個關(guān)閉了SMT的物理核進行計算??偤臅r為38.562s。
Test7:別名“假”6核,使用3個開啟了SMT的物理核進行計算??偤臅r為58.843s。
Test8:別名“真”3核,使用3個關(guān)閉了SMT的物理核進行計算??偤臅r為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
責(zé)任編輯:haq
-
smt
+關(guān)注
關(guān)注
43文章
3047瀏覽量
72052 -
多線程
+關(guān)注
關(guān)注
0文章
279瀏覽量
20445
原文標(biāo)題:超線程SMT究竟可以快多少?(斐波那契版)
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
I/O密集型任務(wù)開發(fā)指導(dǎo)
CPU密集型任務(wù)開發(fā)指導(dǎo)
借助NVIDIA技術(shù)實現(xiàn)機器人裝配和接觸密集型操作

告別性能瓶頸:使用 Google Coral TPU 為樹莓派注入強大AI計算力!

請問如何在Python中實現(xiàn)多線程與多進程的協(xié)作?
金倉數(shù)據(jù)庫入選《2024年度專利密集型產(chǎn)品名單》

L-com諾通推出新型6類屏蔽型超薄以太網(wǎng)線纜
揭秘SMT貼片加工價格計算:全方位解析成本構(gòu)成
FP8在大模型訓(xùn)練中的應(yīng)用

AMD Alveo V80計算加速器網(wǎng)絡(luò)研討會
AMD推出EPYC Embedded霄龍嵌入式8004系列處理器
人員定位系統(tǒng)對生產(chǎn)密集型企業(yè)的重要意義

廣和通端側(cè)AI解決方案驅(qū)動性能密集型場景商用型場景商用
廣和通端側(cè)AI解決方案驅(qū)動性能密集型場景商用型場景商用

評論