※ 引述《JohnLinq (林約翰)》之銘言： : 冒昧請教幾個問題。 : ※ 引述《ggg12345 (ggg)》之銘言： : > 一般使用高階語言程式與高階API者應該不會處理的這麼細. 這已 : > 經是類似粗放與細耕的代價/獲益問題. : 那麼，從軟體人的角度來看， : CPU內部，如何實現硬體的多執行緒，似乎是太過細節的問題， : 如此一來，粗放與細耕應該如何取捨呢？ : (通通交給作業系統與編譯器嗎？) 交給 OS 會消耗 runtime 資源， 交給 compiler 會有難以預測 runtime 行為的問題而太保守， 純手工來 tune 通常是最好的， 至於要 tune 哪裡可以看 profiling 結果來決定， 一開始你可以都交給 OS or compiler。 : > Multi-thread 要發揮效用, 程式設計者就要考慮到相當細節的部份, 同 : > 步與切換的排程問題都得親自處理, 才能發揮出併行處理又無太多 overhead : > 的效用. : > 由 compiler 與 library API 支援的 multi-thread 在啟動與切換 thread : > 時就是讓不同 thread 使用不同的 register set. 在共用 process memory : > space 與工作環境的假設下, user program 的 threads 間不會自尋煩惱的相互 : > 干擾, 因此就不必類似 multi-process 般的做此制式 save/restore 動作. 而 : > 使用不同組的 register set, 當然更是不必全做存回 memory 的 save/restore : > 動作, 此類 overhead 就省了. : > Multi-thread program 通常寫成同一份的 program 給 compiler 編譯, 同 : > 時指明要使用 thread 特性, 此時 compiler 就可細查會相互干擾的 register : > 有那些, 在切換時就可只針對會干擾到的 register 做最有效的暫存與還原. : 使用類似POSIX Threads這樣的東西，軟體人是不是就需要考慮較多的硬體細節？ : 而當使用OpenMP、Intel Threading Building Blocks這樣的東西的時候， : 就可以把硬體細節丟給Compiler與Library API； : 是這樣嗎？ 沒聽說過用 pthread 就要考慮到硬體， 頂多去瞭解它是什麼 thread model， 是不是在 kernel space， 還有是 compiler 還是 library 支援而已， 這些都是完全在軟體角度思考， 除非你想去搞清楚每個 cycle 的時間到底被花在哪裡。 稍稍深入分析 multi-thread 程式的效能時， 難免就多少會跟 computer architecture 有點關係， 但是它並非硬體「細節」， 只是一個抽象概念而已， 你就算用了 OpenMP 還是其它什麼的要深究的話還是會接觸到， 比方說你要去看 compiler 到底怎樣處理那些 directives， 然後鑽進 library or OS 裡面追查 thread 到底是被怎樣處理的， 最後還是得去瞭解你執行環境的電腦是什麼樣的架構， 然後去追 cache、speculation、prediction 等等有的沒的參數， 這些在你真的想去抓最根本的原因時都不可能避免； 就算你是寫 Java 用的是 Java Thread， 你想追根究底的時候也不可能永遠在抽象的 VM 層級上看， 畢竟真正影響程式執行效率的還是 architecture 本身。 所謂硬體細節一般是指 organization 的部分， 不需要跳到這麼底層來寫程式已經很好了， 這不是文字遊戲， architecture 本身就是被定位在偏寫程式相關的那邊， 在你需要斤斤計較的時候無視 architecture 特性是不可能的， 不會因為是以哪種形式支援 thread 而有所差異。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://www.tinlans.org --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.160.114.73