chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

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

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

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

探究SMT對(duì)計(jì)算密集型workload的效果

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

掃碼添加小助手

加入工程師交流群

宋老師的SMT測(cè)試很有意思,但是編譯內(nèi)核涉及的因素太多了,包括訪問文件系統(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ú)疑問,這是一個(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)配置,開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線程)。總耗時(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ì),你沒看錯(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)這樣違反直覺的結(jié)果?

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

圖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??偤臅r(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ì)算??偤臅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ī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • smt
    smt
    +關(guān)注

    關(guān)注

    44

    文章

    3108

    瀏覽量

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

    關(guān)注

    0

    文章

    279

    瀏覽量

    20779

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

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

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

掃碼添加小助手

加入工程師交流群

    評(píng)論

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

    【產(chǎn)品介紹】Altair HPCWorks高性能計(jì)算管理平臺(tái)(HPC平臺(tái))

    AltairHPCWorksAltair高性能計(jì)算平臺(tái)最大限度地利用復(fù)雜的計(jì)算資源,并簡(jiǎn)化計(jì)算密集型任務(wù)的工作流程管理,包括人工智能、建模和仿真,以及可視化應(yīng)用。強(qiáng)大的
    的頭像 發(fā)表于 09-18 17:56 ?401次閱讀
    【產(chǎn)品介紹】Altair HPCWorks高性能<b class='flag-5'>計(jì)算</b>管理平臺(tái)(HPC平臺(tái))

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

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

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

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

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

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

    告別性能瓶頸:使用 Google Coral TPU 為樹莓派注入強(qiáng)大AI計(jì)算力!

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

    請(qǐng)問如何在Python中實(shí)現(xiàn)多線程與多進(jìn)程的協(xié)作?

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

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

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

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

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

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

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

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

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

    SMT產(chǎn)線固定讀碼器的應(yīng)用效果

    在當(dāng)今高度自動(dòng)化的制造業(yè)中,SMT(表面貼裝技術(shù))產(chǎn)線作為電子組裝的核心環(huán)節(jié),其效率與精度直接影響著產(chǎn)品的質(zhì)量與成本。而SMT產(chǎn)線固定讀碼器的應(yīng)用,無(wú)疑是這一領(lǐng)域內(nèi)的一次重要技術(shù)革新,為生產(chǎn)流程帶來(lái)
    的頭像 發(fā)表于 12-10 15:48 ?619次閱讀
    <b class='flag-5'>SMT</b>產(chǎn)線固定讀碼器的應(yīng)用<b class='flag-5'>效果</b>

    使用 AMD Versal AI 引擎釋放 DSP 計(jì)算的潛力

    的 DSP 應(yīng)用。 AMD Versal AI 引擎使您能夠擴(kuò)展數(shù)字信號(hào)處理 (DSP) 計(jì)算和面向未來(lái)的設(shè)計(jì),以適應(yīng)當(dāng)前和下一代計(jì)算密集型 DSP 應(yīng)用。借助 Versal AI 引擎,客戶可以期望以
    的頭像 發(fā)表于 11-29 14:07 ?1549次閱讀

    探索1.6kWT三級(jí)PFC電源:新一代電源效率

    隨著我們的世界越來(lái)越依賴能源密集型設(shè)備,電源裝置必須跟上效率和可靠性標(biāo)準(zhǔn)。東芝電子設(shè)備及存儲(chǔ)設(shè)備公司設(shè)計(jì)的1.6kWT三級(jí)功率因數(shù)校正(PFC)電源是電源管理的一次飛躍,為各種電子系統(tǒng)提供高效的高功率輸出。
    的頭像 發(fā)表于 11-15 17:32 ?1231次閱讀
    探索1.6kWT<b class='flag-5'>型</b>三級(jí)PFC電源:新一代電源效率

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

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

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

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