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