※ 引述《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)