99精品伊人亚洲|最近国产中文炮友|九草在线视频支援|AV网站大全最新|美女黄片免费观看|国产精品资源视频|精彩无码视频一区|91大神在线后入|伊人终合在线播放|久草综合久久中文

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

探究SMT對計算密集型workload的效果

Linux閱碼場 ? 來源:Linux閱碼場 ? 作者:紅燒的威化餅 ? 2021-10-28 15:40 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

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

為了探究SMT對計算密集型workload的效果,我自己寫了一個簡單的測試程序。

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

workload的詳細代碼和測試腳本在[https://github.com/HongweiQin/smt_test]

毫無疑問,這是一個計算密集型負載,我在自己的筆記本上運行,配置如下(省略了一些不重要的項目):
$ 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

可以看到筆記本有一個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 4000000000threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=32real0m45.003suser7m12.953ssys0m0.485s

Test2:把smt關(guān)掉,同樣的測試方法(12線程)??偤臅r為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

對,你沒看錯。同樣的workload,如果關(guān)掉smt,總耗時還變少了。Intel誠不欺我!

Test3:再次允許smt,但是將程序限制在三個物理Core上運行,則總耗時為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會出現(xiàn)這樣違反直覺的結(jié)果?

猜想:Cache一致性在作怪!8dc67c6e-37a5-11ec-82a8-dac502259ad0.png

圖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 4096threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096real0m13.193suser2m31.091ssys0m0.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 4096threads_num=12, fibonacci_max=4000000000, should_set_affinity=0, should_inline=1, alloc_granularity=4096real0m24.841suser2m26.253ssys0m0.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#!/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)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • smt
    smt
    +關(guān)注

    關(guān)注

    43

    文章

    3047

    瀏覽量

    72052
  • 多線程
    +關(guān)注

    關(guān)注

    0

    文章

    279

    瀏覽量

    20445

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

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    I/O密集型任務(wù)開發(fā)指導(dǎo)

    使用異步并發(fā)可以解決單次I/O任務(wù)阻塞的問題,但是如果遇到I/O密集型任務(wù),同樣會阻塞線程中其它任務(wù)的執(zhí)行,這時需要使用多線程并發(fā)能力來進行解決。 I/O密集型任務(wù)的性能重點通常不在于CPU的處理
    發(fā)表于 06-19 07:19

    CPU密集型任務(wù)開發(fā)指導(dǎo)

    CPU密集型任務(wù)是指需要占用系統(tǒng)資源處理大量計算能力的任務(wù),需要長時間運行,這段時間會阻塞線程其它事件的處理,不適宜放在主線程進行。例如圖像處理、視頻編碼、數(shù)據(jù)分析等。 基于多線程并發(fā)機制處理CPU
    發(fā)表于 06-19 06:05

    借助NVIDIA技術(shù)實現(xiàn)機器人裝配和接觸密集型操作

    本期 NVIDIA 機器人研究與開發(fā)摘要 (R2D2) 將探討 NVIDIA 研究中心針對機器人裝配任務(wù)的多種接觸密集型操作工作流,以及它們?nèi)绾谓鉀Q傳統(tǒng)固定自動化在魯棒性、適應(yīng)性和可擴展性等方面的關(guān)鍵挑戰(zhàn)。
    的頭像 發(fā)表于 06-04 13:51 ?224次閱讀
    借助NVIDIA技術(shù)實現(xiàn)機器人裝配和接觸<b class='flag-5'>密集型</b>操作

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

    使用機器學(xué)習(xí)的應(yīng)用程序通常需要高計算能力。這些計算通常發(fā)生在顯卡的GPU上。RaspberryPi并不專門設(shè)計用于運行計算密集型應(yīng)用程序。但GoogleCoralUSB加速器能在此提供
    的頭像 發(fā)表于 03-25 09:30 ?742次閱讀
    告別性能瓶頸:使用 Google Coral TPU 為樹莓派注入強大AI<b class='flag-5'>計算</b>力!

    請問如何在Python中實現(xiàn)多線程與多進程的協(xié)作?

    大家好!我最近在開發(fā)一個Python項目時,需要同時處理多個任務(wù),且每個任務(wù)需要不同的計算資源。我想通過多線程和多進程的組合來實現(xiàn)并發(fā),但遇到了一些問題。 具體來說,我有兩個任務(wù),一個是I/O密集型
    發(fā)表于 03-11 06:57

    金倉數(shù)據(jù)庫入選《2024年度專利密集型產(chǎn)品名單》

    2月8日, 國家專利密集型產(chǎn)品備案認定試點平臺公布了《2024年度專利密集型產(chǎn)品名單》,由電科金倉自主研發(fā)的金倉數(shù)據(jù)庫管理系統(tǒng)(KingbaseES)憑借扎實的技術(shù)積淀與市場驗證,成功入選該名
    的頭像 發(fā)表于 02-23 15:42 ?468次閱讀
    金倉數(shù)據(jù)庫入選《2024年度專利<b class='flag-5'>密集型</b>產(chǎn)品名單》

    L-com諾通推出新型6類屏蔽超薄以太網(wǎng)線纜

    密集型布線對線纜要求更高,L-com諾通為了更好完善客戶高密度布線應(yīng)用,推出了新型6類屏蔽超薄以太網(wǎng)線纜。
    的頭像 發(fā)表于 02-21 09:36 ?388次閱讀

    揭秘SMT貼片加工價格計算:全方位解析成本構(gòu)成

    一站式PCBA智造廠家今天為大家講講SMT貼片加工廠價格計算方法有哪些?SMT貼片加工廠價格計算方法。在電子制造行業(yè),SMT貼片加工是PCB
    的頭像 發(fā)表于 02-13 09:16 ?599次閱讀

    FP8在大模型訓(xùn)練中的應(yīng)用

    越來越多的技術(shù)團隊開始使用 FP8 進行大模型訓(xùn)練,這主要因為 FP8 有很多技術(shù)優(yōu)勢。比如在新一代的 GPU 上,F(xiàn)P8 相對于 BF16 對矩陣乘算子這樣的計算密集型算子,NVIDIA
    的頭像 發(fā)表于 01-23 09:39 ?1185次閱讀
    FP8在大模型訓(xùn)練中的應(yīng)用

    AMD Alveo V80計算加速器網(wǎng)絡(luò)研討會

    歡迎參加本次網(wǎng)絡(luò)研討會,我們將深入探討 AMD Alveo V80 計算加速器如何幫助您處理高性能計算、數(shù)據(jù)分析、金融科技、網(wǎng)絡(luò)安全、存儲加速、AI 計算等領(lǐng)域的內(nèi)存密集型工作負載。A
    的頭像 發(fā)表于 11-08 09:35 ?639次閱讀

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

    在JAVA中確定線性池大小,分別介紹CPU密集型任務(wù)和I/O密集型任務(wù)及其處理方法。
    的頭像 發(fā)表于 10-24 14:02 ?482次閱讀

    AMD推出EPYC Embedded霄龍嵌入式8004系列處理器

    AMD近日正式推出了全新的EPYC Embedded霄龍8004系列處理器,為計算密集型嵌入式系統(tǒng)帶來了更加強勁的性能。
    的頭像 發(fā)表于 10-09 17:32 ?937次閱讀

    人員定位系統(tǒng)對生產(chǎn)密集型企業(yè)的重要意義

    發(fā)電、供電、石油化工、鋼鐵冶金行業(yè)為生產(chǎn)設(shè)備密集型企業(yè),生產(chǎn)現(xiàn)場錯綜復(fù)雜,稍有不慎便會發(fā)生危險;建筑工地現(xiàn)場施工作業(yè)中,存在著人員流動性大、現(xiàn)場狀況雜亂、安全隱患難以察覺等問題;工廠安全管理混亂
    的頭像 發(fā)表于 09-10 17:30 ?550次閱讀
    人員定位系統(tǒng)對生產(chǎn)<b class='flag-5'>密集型</b>企業(yè)的重要意義

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

    2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側(cè)AI解決方案高效使能性能密集型場景。該端側(cè)AI解決方案整合強大AI算力、邊緣側(cè)AI數(shù)據(jù)分析及Wi-Fi 7連接方式,可為自主移動機器人、工業(yè)無人機、云服務(wù)器和AI邊緣計算盒子等物聯(lián)網(wǎng)應(yīng)用提供端側(cè)
    的頭像 發(fā)表于 08-23 16:06 ?614次閱讀

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

    2024世界機器人大會期間,廣和通宣布:基于高通QCS8550平臺的廣和通端側(cè)AI解決方案高效使能性能密集型場景。該端側(cè)AI解決方案整合強大AI算力、邊緣側(cè)AI數(shù)據(jù)分析及Wi-Fi 7連接方式,可為自主移動機器人、工業(yè)無人機、云服務(wù)器和AI邊緣計算盒子等物聯(lián)網(wǎng)應(yīng)用提供端側(cè)
    的頭像 發(fā)表于 08-23 16:05 ?1019次閱讀
    廣和通端側(cè)AI解決方案驅(qū)動性能<b class='flag-5'>密集型</b>場景商用<b class='flag-5'>型</b>場景商用