Re: [問題] 使用執行緒後執行時間變長

看板C_and_CPP (C/C++)作者 (卡馬請出來面對!!)時間14年前 (2012/03/21 22:50), 編輯推噓1(1047)
留言48則, 4人參與, 最新討論串2/2 (看更多)
※ 引述《nola3388 (nola)》之銘言: : 開發平台(Platform): (Ex: VC++, GCC, Linux, ...) : BCB : 問題(Question): : 原本程式執行壓縮 function 時, 20M 單頻 wav 檔, 壓縮時間為 8 秒, : 但使用執行緒呼叫 function 後, 壓縮時間變成 25 秒, : 想請問是什麼原因造成這種結果, 謝謝. 不一定要用 thread 吧 因為你的 main thread 還是要等 work thread. 還有有帶 UI 的 thread 也會 delay 一下 真的要用 thread 可以把 wav 切多個 wav 然後一起分段處理 這樣比較有意義 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.107.174

03/21 23:16, , 1F
個人也是偏向於用OS的觀點去看待
03/21 23:16, 1F

03/22 16:32, , 2F
請問 os 的觀點是什麼意思?
03/22 16:32, 2F

03/22 16:33, , 3F
另外 目前是一個 THREAD 處理一個 WAV 檔
03/22 16:33, 3F

03/22 19:00, , 4F
OS是作業系統,你要去想thread實際上是怎麼做到的
03/22 19:00, 4F

03/22 19:01, , 5F
知道thread的運作原理之後,才比較能知道怎樣會快
03/22 19:01, 5F
BCB 的 TThread 會開一個隱藏的 window 用來 swap UI message 建議自己用 craetethread() 效能會比較好 況且你只處理一個 wav 那用 main thread 處理不是一樣嗎? 還減少 context switch 次數 效能會很快 請去 google 'work thread' & 'ui thread' 的差別 ※ 編輯: chengcti 來自: 114.43.107.174 (03/22 22:50)

03/22 23:39, , 6F
thread底層是由process來做到的
03/22 23:39, 6F

03/22 23:40, , 7F
然而thread與process的對應並不一定,一對一 多對一
03/22 23:40, 7F

03/22 23:41, , 8F
都有可能。OS真正在處理的時候是以process為單位在執行
03/22 23:41, 8F

03/22 23:42, , 9F
使用thread能夠加速,必須有許多條件都成立才行
03/22 23:42, 9F

03/22 23:43, , 10F
演算法本身可以平行計算、OS也能夠平行計算這些thread
03/22 23:43, 10F

03/22 23:44, , 11F
有的thread是以輪流執行的方式達到並行的假象
03/22 23:44, 11F

03/22 23:45, , 12F
那麼也不會變快,還多加上了切換的時間 (switch)
03/22 23:45, 12F

03/23 10:05, , 13F
謝謝 關於 BCB thread, work thread 和 ui thread 會再
03/23 10:05, 13F

03/23 10:06, , 14F
細看, 因為壓縮 function 是別人先寫好的, 希望可以在不
03/23 10:06, 14F

03/23 10:08, , 15F
不更動它的情況下顯示進度, 所以才想到用 thread 來作
03/23 10:08, 15F

03/23 10:09, , 16F
所以才建兩條 THREAD 一個跑PROGRESSBAR 一個跑壓縮
03/23 10:09, 16F

03/23 10:09, , 17F
但沒想到時間變拖長這麼久, 所以才想上來問問, 謝謝.
03/23 10:09, 17F

03/25 07:19, , 18F
單 CPU 下多 Thread 沒有意義 只是增加 thread switch
03/25 07:19, 18F

03/25 07:20, , 19F
時的 overhead.
03/25 07:20, 19F

03/25 07:21, , 20F
就算是多CPU下的 OpenMP 也不太可能速度會是原本的 2 倍
03/25 07:21, 20F

03/25 07:22, , 21F
但你要遇更多的 dead lock 還有不可預期結速的問題
03/25 07:22, 21F

03/25 07:23, , 22F
通常會用到 multi thread 都是一個 thread 要等 I/O
03/25 07:23, 22F

03/25 07:24, , 23F
另一個 thread 負責 algorithm. 這時才會用 multi thread
03/25 07:24, 23F

03/25 07:25, , 24F
要加速演算法不會用 multithread. 用的是 mmx, sse, sse2 .
03/25 07:25, 24F

03/25 07:25, , 25F
多媒體指令集.
03/25 07:25, 25F

03/25 07:27, , 26F
可以參考一下 ffmpeg 這 library 裡頭都寫好一些加速的
03/25 07:27, 26F

03/25 07:27, , 27F
code
03/25 07:27, 27F

03/25 07:28, , 28F
而且 for any arch
03/25 07:28, 28F

03/25 07:29, , 29F
若要 multithread 做 I/O 加速. 後來幾乎都改用 non-block
03/25 07:29, 29F

03/25 07:30, , 30F
I/O. 原因在於 project 在越來越肥時 multi thread 會變
03/25 07:30, 30F

03/25 07:30, , 31F
的越來越不可預期
03/25 07:30, 31F

03/25 07:31, , 32F
舉個例子 open source 裡的 live555 裡頭就有一個經典的
03/25 07:31, 32F

03/25 07:32, , 33F
non block I/O queue. 而且我這邊測試 performance 還不差
03/25 07:32, 33F

03/25 07:33, , 34F
你的問題在於使用 multi thread 是要解決什麼問題?
03/25 07:33, 34F

03/25 07:35, , 35F
盡量朝 non block 去思考會比較好.
03/25 07:35, 35F

03/25 07:36, , 36F
因為那才步會產生更多的 isseus and debug time
03/25 07:36, 36F

03/25 07:36, , 37F
再舉個例子 QT Framework 裡頭的 SIGNAL and SLOT 也是一個
03/25 07:36, 37F

03/25 07:37, , 38F
經典的例子. 就我公司 project 下同樣產品. 一個使用
03/25 07:37, 38F

03/25 07:38, , 39F
MFC 一個使用 QT. 但 QT 開發快速而且 performance 好 MFC
03/25 07:38, 39F

03/25 07:38, , 40F
太多. 其原因在於 MFC Project 有太多歷史共業 (學長們的
03/25 07:38, 40F

03/25 07:39, , 41F
try & error code 在裡頭. multi thread 被濫用的嚴重 導致
03/25 07:39, 41F

03/25 07:40, , 42F
dead lock isseus and bad performance program
03/25 07:40, 42F

03/25 07:41, , 43F
若真要使用 Multi Thread . 建議先設計一套穩定的 Thread
03/25 07:41, 43F

03/25 07:42, , 44F
Manager. 並且經過壓力測試. 再拿此套 Thread Manager 來
03/25 07:42, 44F

03/25 07:42, , 45F
使用.
03/25 07:42, 45F

03/25 07:43, , 46F
不要 CreatThread 就射後不理了.
03/25 07:43, 46F

03/25 07:45, , 47F
因為 ... 學長也曾被 學長的學長荼毒過
03/25 07:45, 47F

03/26 10:40, , 48F
原來如此, 謝謝.
03/26 10:40, 48F
文章代碼(AID): #1FQUhDHb (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #1FQUhDHb (C_and_CPP)