Re: [問題] 有關古老程式跑在多核平台上的問題?
※ 引述《lkerr (kerr)》之銘言：
: 現在的Virtual Machine, 例如 Xen,KVM,VMWare ESX,Virtualbox(xVM),Hyper-V,
: 要有效率的跑在x86或ia-64, 都會透過VT等技術,
: 這是因為x86的架構不符合 Popek and Goldberg virtualization requirements,
: 根據我使用以上VM的經驗, 古老程式並不會利用到多核心的好處,
: 因為利用到VT, 所以同一時間, 古老程式只會跑在一個核心上,
: 除非是Full Virtualization, 但古早的Vmware 的效能大家都知道是很差的,
為何說 "除非是 Full Virtualization" ?
很想知道為何有此看法 ?
照 Goldberg 的說法是 sensitive instruction 若皆為 priviledge
instruction , 這個機器就能具備辦到 virtualization 的條件.
但這件事在何處跟虛擬化有關 ?
在 X86 還沒有 Floating Point Processing Unit 硬體支援之前,
X86 只有整數的加減乘除指令, 浮點運算是呼叫 function call
用整數運算方法合成. 有了 FPU 就定義了浮點運算指令與存放浮
點數值的置數器. 假如 386 chip 沒有浮點置數器, 那也是可以用
程式宣告虛擬的浮點置數器與 浮點運算function-call 來模擬不
存在的FPU.
繫結時, 是使用真實指令還是虛擬功能的浮點運算 Library , 只
要能檢視 FPU 是否存在且可用, 就可以做出決定. 但若要全部都
用整數模擬完全不用 FPU 來做也是可以的.
FPU 硬體的利用就有三個階段:
1.之前
2.之後, 事前設定後完全選用其一
3.自動按狀況, 隨情況選用與調派
照 multi-process/thread 的概念, 第三者狀況應該還沒有發生,
因為後來的 X86 將 FPU 做進了 processor unit 之內, 多機並
不共用單獨的 FPU , 也就不像 I/O unit 那樣是調派 FPU 來用.
多核是做在同一個 chip 之內, 為了省電散熱, 是否每個核都要
配置 FPU 就有討論的空間. 所以第三種狀況會發生.
硬體做的 FPU 在資料處理的長度與並行度比用軟體模擬的浮點運
算程式來得高速高效, 到處都需要用到, 所以內建於 X86.
現在問題可以類似的這樣問:
假如有一個老式程式是在 FPU 供應之前就發展完成, 在使用有
FPU 的 X86 之後, 能不能不更改原程式使之有利用到 FPU 之效
果 ?
這裡根據歷史演化會有幾種狀況:
1.浮點運算的軟體沒有標準浮點格式, 表示法與 FPU 不同.
2.有 FPU 之後, 為了兼容, 沒有 FPU 的機器也採納與 FPU 相
同的格式與運算指令當 macro-instruction 或 function call.
3.將來在多核下, 可能會有動態的 FPU 使用與軟體模擬並用.
就 intel 的立場, 在 FPU 外掛的時代, 她會希望 FPU 做到 pnp
自動切換與使用的效果, 她的做法類似 virtual memory 的 page
fault trap, 但沒有採用 Virtual FPU 的說法, 而是稱為
co-processor. 因為外掛的 FPU 可以像 I/O unit 那樣把 FPU 運
算指令透過共用 BUS 丟給 FPU, 等候其將結果回應, 若沒有回應
就是 time-out. 以 exception trap 改用軟體模擬.
現在的多核問題比 FPU co-processor 難一點, 變成是多核是否可
以成為其中一核的 co-processor, 協助其同時處理或代替處理 ?
就概念言, 多核在此 co-processing 情況下是屬於 SIMD 性質, 這
部份最可能的做法就是 vector-computing 也就是多核必須於必要
時, 能動態組成 vector processor, 不需要時就拆解為 MIMD 性質.
當程式使用 vector processor 的 架構與instruction 時, 這個問
題至少可以類似的做到自動使用多核做平行的 vector processing.
這種跟資源堪用與否的 instruction 跟 virtual memory 的 operand
checking 是類似的性質, 並不是每次碰到都要 trap 到特權域.
就商業與經濟面的立場, 能具備動態切換 MIMD 與 SIMD 資源配置的
processor 一定是另外針對用戶需求來賣的, 彈性與多功能並非一般
使用者所需, 所以這種能用到多核變成 SIMD vector processing 的
軟體當然也是不會廉價的供應.
當然, 在多媒體與電玩的時代, 需要高速處理也是很迫切的.
: 所以現在很少人會用Full Virtualization
若照上面的假設與比擬, 需要用到 Full Virtualization 嗎 ?
換個方式當然另當別論, 那是用那種方式來達到目標 ?
: 這裡所說的Virtual Machine 是 System Virtual Machine,
: 而要讓古老程式跑在多核心上, Process Virtual Machine
: 應該比較適, 就像JVM, .Net Framework,
: 可是這程式是C/C++ 開發的 T_T
最可能快速實現的方案, 若比照 FPU 的歷史, 最可能的事就是把
使用 Vector FORTRAN 寫的程式從 昂貴的 Vector Computer 移到
多核心的 X86 上很省電又很高速, 不必更改就能同樣處理.
不過, 很遺憾, Vector Computer 並不採用 X86 架構與指令集,
要這樣地將所有指令全模擬, 才有 Emulation 的問題.
所以, 現在是處於 X86 Vector-Processor 還沒有被定義與設定指
令的 "之前" 階段, 是甚麼都有可能也都不太可能的階段, 但這個
趨勢與方向幾乎是可預測與用過往的經驗可拿來來參考的時候.
C++ 跟 Java 在 concurrent operation 的支援上有所不同, 但
某些 Java 號稱可以 併行 , 可是 Java interpreter 似乎也少有
利用多核功能的(?? , 待解疑).
Java interpreter 理論上可以把執行 java code 的元件用 thread
方式來對應 cocurrent part 來進行, 這種方式應該可以在多機上透
過底層的 OS 來支援, 多核應該也是可以做到.
但 object oriented 的 Java 是遵從 message passing 的機制, 對
shared memory MP 或 single chip multi-core 又顯得太偏向網路
連接的架構, 概念上不是那麼適配. 當然, 多核也可以在 chip 內做
個 switch 與 queue 來擬似, 但在處理大量 array data 與傳送時,
在概念上實在不是與多核硬體很匹配.
沒好的解之下, 多核心引發的問題一定是得持續吵鬧好幾年 ! 但如同
386 出來很久, OS 也是拖了很久才用上 window 多工與 Virtual
Memory 的功能, 但學院派對之也不覺得有值得炒熱的地方, 因為趨勢
與方向做法都大致已知, 何況 MS 也不想公開做法, 使得冷的局面多.
==================
台灣沒公司造尖端的 processor , 但還是可以亂掰與學習先進的
processor architecture 與 VM/OS. (哈 ! 學了給誰用 ? 老共嗎 ?)
※ 編輯: ggg12345 來自: 140.115.4.12 (08/05 19:47)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 10 篇)：