久久五月丁香合缴情网,亚洲黄一级黄片免费毛片,久久精品国产亚洲AV麻豆～

宋老師的SMT測(cè)試很有意思，但是編譯內(nèi)核涉及的因素太多了，包括訪問(wèn)文件系統(tǒng)等耗時(shí)受到存儲(chǔ)器性能的影響，難以估算，因此很難評(píng)判SMT對(duì)性能的提升如何。

為了探究SMT對(duì)計(jì)算密集型workload的效果，我自己寫了一個(gè)簡(jiǎn)單的測(cè)試程序。

使用pthread開(kāi)多個(gè)線程，每個(gè)線程分別計(jì)算斐波那契數(shù)列第N號(hào)元素的值。每個(gè)線程計(jì)算斐波那契數(shù)列時(shí)除線程的元數(shù)據(jù)外只分配兩個(gè)unsigned long變量，由此避免過(guò)高的內(nèi)存開(kāi)銷。

workload的詳細(xì)代碼和測(cè)試腳本在[https://github.com/HongweiQin/smt_test]

毫無(wú)疑問(wèn)，這是一個(gè)計(jì)算密集型負(fù)載，我在自己的筆記本上運(yùn)行，配置如下（省略了一些不重要的項(xiàng)目）：

$ lscpuArchitecture:                    x86_64CPU(s):                          12On-line CPU(s) list:             0-11Thread(s) per core:              2Core(s) per socket:              6Socket(s):                       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)配置，開(kāi)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.sh#!/bin/bash
echo "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ú)效化。由此可見(jiàn)，如果程序一直這樣運(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線程，開(kāi)啟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è)開(kāi)啟了SMT的物理核進(jìn)行計(jì)算?？偤臅r(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.sh#!/bin/bash
fibonacci=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=4096 real0m38.562suser3m50.786ssys0m0.000sturn on smtthreads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 real0m58.843suser5m53.018ssys0m0.005sturn off smtthreads_num=6, fibonacci_max=20000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096 real1m13.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

smt

+關(guān)注

關(guān)注
40

文章
2905

瀏覽量
69312
多線程

多線程

+關(guān)注

關(guān)注
0

文章
278

瀏覽量
19981

原文標(biāo)題：超線程SMT究竟可以快多少？（斐波那契版）

文章出處：【微信號(hào)：LinuxDev，微信公眾號(hào)：Linux閱碼場(chǎng)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

評(píng)論

相關(guān)推薦

怎么在JAVA中確定線性池大小

在JAVA中確定線性池大小，分別介紹CPU密集型任務(wù)和I/O密集型任務(wù)及其處理方法。

發(fā)表于 10-24 14:02 ?193次閱讀

人員定位系統(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)題；工廠安全管理混亂

發(fā)表于 09-10 17:30 ?268次閱讀

人員定位系統(tǒng)對(duì)生產(chǎn)<b class='flag-5'>密集型</b>企業(yè)的重要意義

廣和通端側(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è)

發(fā)表于 08-23 16:06 ?318次閱讀

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

發(fā)表于 08-23 16:05 ?667次閱讀

廣和通端側(cè)AI解決方案驅(qū)動(dòng)性能<b class='flag-5'>密集型</b>場(chǎng)景商用<b class='flag-5'>型</b>場(chǎng)景商用

高性能計(jì)算中的芯片架構(gòu)設(shè)計(jì)探索

芯片行業(yè)非常清楚，對(duì)于許多計(jì)算密集型應(yīng)用而言，單芯片解決方案已變得不現(xiàn)實(shí)。過(guò)去十年的最大問(wèn)題是，向多芯片解決方案的轉(zhuǎn)變何時(shí)才能成為主流。

發(fā)表于 04-19 11:21 ?921次閱讀

高性能<b class='flag-5'>計(jì)算</b>中的芯片架構(gòu)設(shè)計(jì)探索

傳統(tǒng)用于數(shù)字設(shè)計(jì)的CPU是否已經(jīng)達(dá)到了容量極限？

在數(shù)字設(shè)計(jì)的Implementation過(guò)程中，從RTL到GDSII的每一步都是高度計(jì)算密集型的。

發(fā)表于 04-17 10:11 ?450次閱讀

鴻蒙OS開(kāi)發(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

發(fā)表于 04-01 22:25 ?850次閱讀

鴻蒙OS開(kāi)發(fā)實(shí)例：【ArkTS類庫(kù)多線程CPU<b class='flag-5'>密集型</b>任務(wù)TaskPool】

鴻蒙OS開(kāi)發(fā)實(shí)例：【ArkTS類庫(kù)多線程I/O密集型任務(wù)開(kāi)發(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ā)表于 04-01 16:32 ?523次閱讀

鴻蒙OS開(kāi)發(fā)實(shí)例：【ArkTS類庫(kù)多線程I/O<b class='flag-5'>密集型</b>任務(wù)開(kāi)發(fā)】

博泰“車聯(lián)網(wǎng)云服務(wù)平臺(tái)”入選2023年度專利密集型產(chǎn)品名單

近日，中國(guó)專利保護(hù)協(xié)會(huì)首次組織開(kāi)展了專利密集型產(chǎn)品認(rèn)定工作，并于近期發(fā)布2023年專利密集型產(chǎn)品名單，博泰的“車聯(lián)網(wǎng)云服務(wù)平臺(tái)”入選2023年度專利密集型產(chǎn)品名單。

發(fā)表于 03-29 10:23 ?464次閱讀

博泰“車聯(lián)網(wǎng)云服務(wù)平臺(tái)”入選2023年度專利<b class='flag-5'>密集型</b>產(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)。

發(fā)表于 03-29 09:16 ?553次閱讀