[問題] SSE指令跟多執行緒同時用有助於效能嗎？

看板C_and_CPP作者 (沒有存在感的人)時間9年前 (2016/11/13 03:15), 9年前編輯推噓4(4推 0噓 22→)
留言26則, 5人參與, 最新討論串1/1
開發平台(Platform): (Ex: Win10, Linux, ...) Lubuntu 16.04 編譯器(Ex: GCC, clang, VC++...)+目標環境(跟開發平台不同的話需列出) gcc 5.4.0 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...) pthread, SSE1-4/AVX 問題(Question)： 最近幫忙作code review，看到有人用SSE做計算提高效能。 可是還用多執行緒來跑SSE。 我看了一下，Intel core i7 是每個core有 - 8個 128-bit XMM暫存器(SSE用) - 16 個 256/512-bit 的 YMM(YMM0-YMM15) 暫存器(AVX用) 不管是XMM或YMM空間都很有限。 如果我寫個程式(prog)使用數個thread同時跑， 每個thread都要用滿8個XMM暫存器，那麼： 1.如果兩個thread佔用一個core，會不會因為兩個thread都搶著用XMM使得效能大幅降低？ 我是說因為一個thread要用XMM就把另一個thread放在XMM裡的data踢出去？ (因為XMM load/unload也是有點耗時間) 2.如果剛好某個背景程式或瀏覽器也在同時使用XMM， 那原本prog的效能是不是也會受影響？ 3.如果同時使用XMM/YMM的process會互相影響， 有無辦法可以偵測XMM/YMM是否被使用(如果在使用中我就用普通方法)？ 4. 如果是ARM上面的SIMD/NEON，其效應也是如上？ 感謝回答。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 90.27.42.14 ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1478978113.A.432.html
推
11/13 09:07, , 1F
context switch 會產生的狀況，無論 XMM 或 GPR 都會有
11/13 09:07, 1F
→
11/13 09:09, , 2F
SIMD + MT寫得好應該是會更快，每顆核心都有獨立的 XMM
11/13 09:09, 2F
→
11/13 09:09, , 3F
建議用 Intel VTune 做更多的性能分析
11/13 09:09, 3F
→
11/13 12:49, , 4F
還滿幽默的，寫asm嗎？不然怎麼知道用滿全部暫存器。
11/13 12:49, 4F
我就是不懂暫存器是怎麼管理的， 如果我一次load 10個它會怎麼搞？
→
11/13 15:37, , 5F
1指的不就是thread context switch？
11/13 15:37, 5F
我對pthread不熟，不知道pthread會不會對同一個process的threads 做切換(無sleep的情況下)，一時不知道怎麼找關鍵字。 ※ 編輯: wtchen (90.27.42.14), 11/13/2016 16:53:16 ※ 編輯: wtchen (90.27.42.14), 11/13/2016 16:54:44
推
11/13 19:20, , 6F
你是要問 hyper-thread 是否對 xmm 指令集有效嗎？
11/13 19:20, 6F
→
11/13 19:22, , 7F
如果不考慮 hyper-threading，演算法又有良好平行化
11/13 19:22, 7F
→
11/13 19:22, , 8F
那 2 core 跑 2 thread 當然會比較快
11/13 19:22, 8F
→
11/13 19:22, , 9F
1 core 跑 2 thread 因為多了 overhead 就會慢一點
11/13 19:22, 9F
那如果hyper-thread的情形下， xmm會不會因為thread交互進行而把增加load/store的手續？ 因為xmm只有8個可用.... ※ 編輯: wtchen (90.27.42.14), 11/13/2016 20:29:16
推
11/13 22:14, , 10F
假設沒有 HT 的情況，每個 core 都有自己的一組暫存器
11/13 22:14, 10F
→
11/13 22:14, , 11F
假設有 HT 的情況，每個 logic processor 都有自己的
11/13 22:14, 11F
→
11/13 22:19, , 12F
architecture state，沒記錯裡面也有各自的 GPR 跟 XMM
11/13 22:19, 12F
→
11/13 22:21, , 13F
你在問題多數都跟 context switch 怎樣運作有關
11/13 22:21, 13F
→
11/13 22:23, , 14F
實務上 SIMD + MT 性能會增加，建議實際去跑量測時間
11/13 22:23, 14F
→
11/13 22:26, , 15F
你的所謂 SIMD 暫存器很有限，其實通用暫存器也很有限
11/13 22:26, 15F
→
11/13 22:27, , 16F
相同的問題，在沒有把程式改成 SIMD 之前不就有了 :P
11/13 22:27, 16F
→
11/13 22:27, , 17F
反而是得多注意 false sharing 的問題比較實際
11/13 22:27, 17F
→
11/13 22:38, , 18F
context switch的部分會根據作業系統而定吧，例如
11/13 22:38, 18F
→
11/13 22:39, , 19F
一個有6 core的CPU，是一次一個process，然後可以使用6
11/13 22:39, 19F
→
11/13 22:40, , 20F
thread，還是一次6個process，每個只能使用一個thread
11/13 22:40, 20F
→
11/13 22:40, , 21F
如果在multi core的machine上面，那情況就更複雜，還要
11/13 22:40, 21F
→
11/13 22:41, , 22F
考慮thread被移到另一個CPU的情況上
11/13 22:41, 22F
推
11/13 22:41, , 23F
同意 context switch 得看系統，標題是討論 SSE + MT
11/13 22:41, 23F
→
11/13 22:42, , 24F
我就來貼個 Intel 的一篇文章 https://goo.gl/qegnRl
11/13 22:42, 24F
→
11/13 22:43, , 25F
可以自己看看 SIMD + MT 有沒有幫助...看數據最清楚
11/13 22:43, 25F
所以看起來如果能弄到一個Core一個thread可以有最大效能。 如果有context switch，那xmm裡的變化(load/store)被變成context switch的成本。 這樣了解了。 話說回來我也看了對方做的SSE效能測試的數據，變化超大，據說跟CPU散熱有關。 還真的挺有趣。 ※ 編輯: wtchen (90.27.42.14), 11/13/2016 23:13:00
→
11/14 04:22, , 26F
可以用affinity
11/14 04:22, 26F
‣ 更多 wtchen 的文章
文章代碼(AID): #1O9sf1Go (C_and_CPP)