超線程SMT究竟可以快多少？（斐波那契版）
[導(dǎo)讀]前幾天，宋老師寫了2篇文章：超線程SMT究竟可以快多少？超線程SMT究竟可以快多少？(AMDRyzen版)宋老師的SMT測試很有意思，但是編譯內(nèi)核涉及的因素太多了，包括訪問文件系統(tǒng)等耗時(shí)受到存儲(chǔ)器性能的影響，難以估算，因此很難評(píng)判SMT對(duì)性能的提升如何。?為了探究SMT對(duì)計(jì)算密集...
前幾天，宋老師寫了2篇文章：超線程SMT究竟可以快多少？
超線程SMT究竟可以快多少？(AMD Ryzen版 )
宋老師的SMT測試很有意思，但是編譯內(nèi)核涉及的因素太多了，包括訪問文件系統(tǒng)等耗時(shí)受到存儲(chǔ)器性能的影響，難以估算，因此很難評(píng)判SMT對(duì)性能的提升如何。
?為了探究SMT對(duì)計(jì)算密集型workload的效果，我自己寫了一個(gè)簡單的測試程序。?使用pthread開多個(gè)線程，每個(gè)線程分別計(jì)算斐波那契數(shù)列第N號(hào)元素的值。每個(gè)線程計(jì)算斐波那契數(shù)列時(shí)除線程的元數(shù)據(jù)外只分配兩個(gè)unsigned long變量，由此避免過高的內(nèi)存開銷。?workload的詳細(xì)代碼和測試腳本在[https://github.com/HongweiQin/smt_test]?毫無疑問，這是一個(gè)計(jì)算密集型負(fù)載，我在自己的筆記本上運(yùn)行，配置如下（省略了一些不重要的項(xiàng)目）：
Test2：把smt關(guān)掉，同樣的測試方法（12線程）?？偤臅r(shí)為25.733s。?
Test3相比于Test1用了更少的Core，反而更快了。?為什么在Test2和3會(huì)出現(xiàn)這樣違反直覺的結(jié)果？??猜想：Cache一致性在作怪！?圖1
測試程序的main函數(shù)會(huì)分配一個(gè)含有T(T=nr_threads)個(gè)元素的`struct thread_info`類型的數(shù)組，并分別將每個(gè)元素作為參數(shù)傳遞給每個(gè)計(jì)算線程使用。`struct thread_info`定義如下：?
結(jié)構(gòu)體中的res數(shù)組用于計(jì)算斐波那契數(shù)列，因此會(huì)被工作線程頻繁地寫。?注意到，sizeof(struct thread_info)為32，而我的CPU的cacheline大小為64B！這意味著什么？?圖2
如圖所示，如果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ì)被無效化。由此可見，如果程序一直這樣運(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無效化，程序運(yùn)行時(shí)間也就縮短了。??驗(yàn)證猜想：增加內(nèi)存分配粒度！?對(duì)程序進(jìn)行修改后，可以使用`-g alloc_granularity`參數(shù)設(shè)定tinfo結(jié)構(gòu)體的分配粒度。使用4KB為粒度進(jìn)行分配，再次進(jìn)行測試：?Test4：12線程，開啟SMT，分配粒度為4096?？偤臅r(shí)為13.193s，性能相比于Test1的45.003s有了質(zhì)的提升！?
Test5：在Test4的基礎(chǔ)上限制只能使用3個(gè)物理Core?？偤臅r(shí)為24.841s，基本上是Test4的兩倍。這說明在這個(gè)測試下，多核性能還是線性可擴(kuò)展的。?
超線程SMT究竟可以快多少？?表格和結(jié)論：?
?測試使用的是6個(gè)工作線程。為了減少誤差，增加一點(diǎn)運(yùn)行時(shí)間，每個(gè)線程計(jì)算斐波那契數(shù)列第200億項(xiàng)的值。?對(duì)比Test6和7，可以看到SMT的提升大概在52.6%左右。?測試記錄：?Test6：別名“真”6核，使用6個(gè)關(guān)閉了SMT的物理核進(jìn)行計(jì)算。總耗時(shí)為38.562s。?Test7：別名“假”6核，使用3個(gè)開啟了SMT的物理核進(jìn)行計(jì)算?？偤臅r(shí)為58.843s。?Test8：別名“真”3核，使用3個(gè)關(guān)閉了SMT的物理核進(jìn)行計(jì)算?？偤臅r(shí)為1m13.175s。?
更多精彩，點(diǎn)擊關(guān)注"Linux閱碼場"
超線程SMT究竟可以快多少？(AMD Ryzen版 )
宋老師的SMT測試很有意思，但是編譯內(nèi)核涉及的因素太多了，包括訪問文件系統(tǒng)等耗時(shí)受到存儲(chǔ)器性能的影響，難以估算，因此很難評(píng)判SMT對(duì)性能的提升如何。
?為了探究SMT對(duì)計(jì)算密集型workload的效果，我自己寫了一個(gè)簡單的測試程序。?使用pthread開多個(gè)線程，每個(gè)線程分別計(jì)算斐波那契數(shù)列第N號(hào)元素的值。每個(gè)線程計(jì)算斐波那契數(shù)列時(shí)除線程的元數(shù)據(jù)外只分配兩個(gè)unsigned long變量，由此避免過高的內(nèi)存開銷。?workload的詳細(xì)代碼和測試腳本在[https://github.com/HongweiQin/smt_test]?毫無疑問，這是一個(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，以此類推。?以下的測試(Test 1-5)中，每個(gè)線程分別計(jì)算斐波那契數(shù)列第40億號(hào)元素的數(shù)值。?Test1：采用默認(rèn)配置，開12線程進(jìn)行測試。測試結(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=32?real0m45.003suser7m12.953ssys0m0.485s?Test2：把smt關(guān)掉，同樣的測試方法（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=32?real0m25.733suser2m23.525ssys0m0.116s?對(duì)，你沒看錯(cuò)。同樣的workload，如果關(guān)掉smt，總耗時(shí)還變少了。Intel誠不欺我！?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=32?real0m34.896suser3m17.033ssys0m0.028sTest3相比于Test1用了更少的Core，反而更快了。?為什么在Test2和3會(huì)出現(xiàn)這樣違反直覺的結(jié)果？??猜想：Cache一致性在作怪！?圖1
測試程序的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！這意味著什么？?圖2
如圖所示，如果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ì)被無效化。由此可見，如果程序一直這樣運(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無效化，程序運(yùn)行時(shí)間也就縮短了。??驗(yàn)證猜想：增加內(nèi)存分配粒度！?對(duì)程序進(jìn)行修改后，可以使用`-g alloc_granularity`參數(shù)設(shè)定tinfo結(jié)構(gòu)體的分配粒度。使用4KB為粒度進(jìn)行分配，再次進(jìn)行測試：?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=4096?real0m13.193suser2m31.091ssys0m0.217s?Test5：在Test4的基礎(chǔ)上限制只能使用3個(gè)物理Core?？偤臅r(shí)為24.841s，基本上是Test4的兩倍。這說明在這個(gè)測試下，多核性能還是線性可擴(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=4096?real0m24.841suser2m26.253ssys0m0.032s?超線程SMT究竟可以快多少？?表格和結(jié)論：?
| 測試名? | 硬件配置? | 運(yùn)行時(shí)間(s) |
| Test6 | ?“真”6核?? | 38.562? |
| Test7 | “假”6核? | 58.843 |
| Test8 | “真”3核? | ?73.175? |
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更多精彩，點(diǎn)擊關(guān)注"Linux閱碼場"
下載文檔
