※ 引述《JohnLinq (林約翰)》之銘言： : 冒昧請教幾個問題。 : > 一般使用高階語言程式與高階API者應該不會處理的這麼細. 這已 : > 經是類似粗放與細耕的代價/獲益問題. : 那麼，從軟體人的角度來看， : CPU內部，如何實現硬體的多執行緒，似乎是太過細節的問題， : 如此一來，粗放與細耕應該如何取捨呢？ : (通通交給作業系統與編譯器嗎？) 1.在單核的時代是強調 cpu 的硬體提供多組 register set, multi-thread 可以使用 shared memory. 在切換時可以降低 context switch overhead. 2.在共用 bus 與 common memory 的多處理機的時代, multi-thread 進一步 可強調 parallel thread , 但其同步與排程是在 user space 的 thread library 提供, 因此是減少透過 system call 由 kernel 做同步與排程 的 overhead. 3.在多核心的時代, 目前是以提供多個 program counter, 多組 register set 為開端. 多級的 pipleline functional unit (如陣列浮點運算)跟 簡單的邏輯累算單元可以就其性質, 選擇讓兩個不同性質的程式片段透 過多個 program counter 指向不同的 cache 區段, 同時讓兩個不同的 片段程式(thread 或 process)同時使用不同性質的 functional unit , 如果同時使用到同一組 functional unit 就由 cpu 內部的硬體對不同 片段指令實行延遲禮讓的細部動作. 對這種 functinal unit 的專用( 不做延遲禮讓的交錯使用)當然也可透過事先的聲告來取得, 這時候就依 靠 SMT thread library 提供界面給程式軟體. 程式的使用不外是 user 自理, 不然就是由 程式語言提供 指述 或範例的叫用法, 經由 compiler 半自動協助. ====== 粗放只有一種顧慮就是不要在原則與特性上弄錯. 就像 2-dimension array 在連續取得每個 element 來計算時就必需與 語言的 compiler 安排陣列的方 式相配合, 如 column majoring(FORTRAN) 的大array(如 1024 X 1024) 照 row 的次序先變化 row 去存取, 如果 real memory 不夠大, 就可能造成一堆 的 page fault 使得 page memory 對整個 page 大搬家. 比照於 register set 的 context switch 或 functional pipleline 或 instruction prefetch pipleline 的打斷與重灌, 也就是同樣的道理. : > Multi-thread program 通常寫成同一份的 program 給 compiler 編譯, 同 : > 時指明要使用 thread 特性, 此時 compiler 就可細查會相互干擾的 register : > 有那些, 在切換時就可只針對會干擾到的 register 做最有效的暫存與還原. : 使用類似POSIX Threads這樣的東西，軟體人是不是就需要考慮較多的硬體細節？ : 而當使用OpenMP、Intel Threading Building Blocks這樣的東西的時候， : 就可以把硬體細節丟給Compiler與Library API； : 是這樣嗎？ compiler 當然是企圖朝預測與自動協助方面著手, 但 user 若要故意寫一個 跟其運作原則相反的動作次序, 她也只有被跟著愚弄的下場. 所以, 完全不想知道, 不理她的硬體與編譯原理, 那就是靠運氣在寫程式囉 ! 所謂專業或本科就是多那麼一點點的概念或養成習慣, 靠習慣減少錯誤. : 各個平台與開發工具，對於Thread的支援程度/支援方式，似乎不盡相同， : 您談到了CPU內部的暫存器(資料的存取)， : 能不能也請您談談Pipeline與Functional Unit的部份呢(機器指令的發派)。 細節勢必得針對不同 processor 的架構與指令設計 k 手冊. 若是要專門配屬 某個核心或 functional unit 給特定 thread/process 某段時間使用, 那又 得 k 配合 OS 提供的 thread library , 甚至是 cpu 製造商配合提供的語言 package/compiler&library. 但, 原理原則卻是不太會變的. --

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