: 但是intel本身对SMT的实作有一些问题 : 导致hyper threading没有发挥应有的效能 甚至有时候反而变慢 : 不过我本身不是学这方面的 所以并不是很清楚是怎样的问题 : 有兴趣的人可以去看anandtech的一篇文章 讲得很仔细 : http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2419&p=4 为了让大家更明白 我稍微念过了这篇文章 以下是我的解释 如果有认何错误请大家不吝指正 先简单讲一下p4内部执行x86指令前的过程 存入 指令拮取 指令解码 trace cache | | | | | | | | L2 Cache --> Decoder --> Queue --> Trace Cache --> μOp Queue | | | | 这张图当然是经过了简化...instruction fetch到decode之间还有一个queue 不过先暂时不提它吧 每个x86指令在执行时都须要像上面那样通过一层一层的关卡 首先是从L2 Cache(假设它已经在L2了)中抓到cpu内 (instruction fetch) 指令解码的动作会把它拆成更小的微指令 (μOp) 然後放到地位类似L1 Cache的trach cache中 再进入μOp Queue 这时候才准备好让对应的运算单元执行 x86指令属於CISC架构 所以在指令解码的地方比较复杂 p4的instruction decoder平均两个cycle可以生出六个μOp 这相当於每个cycle中 约有两个x86指令可以被解码 这样的速度在单一thread的情况下是可以被接受的 因为指令间有相依情况 所以同时间有超过两个指令可被执行的情况不多见 但是在hyper-threading的情况下就不同了 因为同时间有两个thread在执行 每个cycle解码两个指令就太慢了 如果指令解码的速度跟不上後面运算单元的速度 那麽运算单元就必须停摆(stall)等待前面的事情先做好 另一方面 虽然hyper-thread多提供了一颗虚拟的cpu 但μOp Queue并没有跟着变两倍大 也就是说 μOp Queue必须切一半来给这两颗虚拟cpu来使用 而这造成的影响就是out-of-order execution的效果变差 先简单说说什麽是out-of-order execution吧 回头看我po的第一篇文 关於指令间相依造成无法平行运作的例子 add eax, ebx add eax, ecx 这两个指令无法同时运作 因为第二个指令必须先等第一个指令完成 但如果这两个指令的後面还有东西... add eax, ebx add eax, ecx add edx, esi add edx, edi 大家可以发现第一个指令和第三个指令没有相依关系 第二个和第四个也没有 所以只要把第二个指令和第三个指令对调 不但效率提高 结果也是正确的 这就是out-of-order execution的想法 cpu只要去分析一连串的指令 找出它们之间的相依关系 就可以藉由重排指令顺序的方式提升效能 但是在hyper-threading的情况下 因为μOp Queue被切了一半 所以对out-of-order execution来说 可以被分析的指令也少了一半 产生的效果就变差了 最後 hyper-threading中 两颗虚拟cpu的L1 cache是共用的 但两支thread的spatial locality并不高 (很难翻译这个名词^^||) 也就是cache更容易miss 上面提到的三种情况 (decode不够快、out-of-order效果不好、cache容易miss) 都会使得运算单元停下来等待(stall) 然而 prescott为了提升时脉 而有了超深的pipeline (31层pipeline stage) 对此也有一定的影响 这就是hyper-threading在p4上无法有效提升效能 甚至拉低效能的原因 : -- :

※ 发信站: 批踢踢实业坊(ptt.cc) : ◆ From: 140.112.244.211 : 推 Dopin:如果程式本身就支援多绪 就没有几 % 的问题 203.70.65.28 06/08 : → Dopin:我想我原文要改一下 感谢 l 兄提醒 :) 203.70.65.28 06/08 : → Dopin:良好的程式结构 也可以最佳化使用 平均於指令 203.70.65.28 06/08 : 推 Dopin:看来造成误解 我改成 "最糟的状况下" 比较不会误会 203.70.65.28 06/08 嗯 我的意思是instruction-level parallelism 也就是降低指令间的相依关系 提升他们被平行处理的可能性 而非多绪 (multi-threading) : 推 singy:你的例子中 add eax,eba 换行 add eax,ecx 61.224.134.53 06/08 : → singy:如果分两组register来计算最後还是要丢回到某个EAX 61.224.134.53 06/08 : → singy:所以这种情况效能就没有增加..... 61.224.134.53 06/08 : → singy:我的第一行eba应该是ebx.... 61.224.134.53 06/08 : → singy:这种情况很常见 所以现在的HT技术因为程式没有针对 61.224.134.53 06/08 : → singy:HT技术作最佳化才会这样 我想应该不会有人这麽无聊 61.224.134.53 06/08 : → singy:为了intel的HT技术做程式最佳化吧...... 61.224.134.53 06/08 不对 add eax, ebx add eax, ecx 这种情况是「没有对superscalar最佳化」 而它很常见的原因并不是因为大家不想做最佳化 而是instruction-level parallelism的最佳化很难做 HT的出现就是为了解决这个问题 只要(理论上)程式可以multi-threading执行 HT就可以让它有效能提升 而把一支程式改成multi-threading 要比instruction-level parallelism要容易许多 另外 只要cpu有提供某些加速的机制 写软体的人就会针对它进行最佳化 这不是什麽无聊不无聊的问题 而是软体卖不卖得出去的问题 :D : 推 singy:我在想 是不是在高阶语言转低阶语言的过程中 61.224.134.53 06/08 : → singy:因为编译器帮忙加了很多不必要的处理 造成一只大 61.224.134.53 06/08 : → singy:project在执行上多少降低其效能? 61.224.134.53 06/08 : → singy:单纯的用组语来写应该能达到高度优化程式的效果..? 61.224.134.53 06/08 对 可是很少人这麽做 因为... 1. 感觉不出差别 像单纯的GUI 0.01秒画出一个按钮 和0.02秒画出一个按钮(多花了100%的时间!) 对使用者是没有差别的 除非他有点100个按钮的需求... 2. 不portable 对cpu A做的最佳化不一定适用於cpu B 尤其硬体改朝换代的情况太常见了 只有少数很偏执的programmer会在新的cpu推出时全部重写他的assembly code (没有批评的意思 我一向很佩服偏执狂) 3. 最重要的问题 程式是写给人看的 现在硬体愈来愈快的结果 使得人们把写程式的重心从效率转移到弹性和维护成本上 当然组合语言不会死 只是全部用组合语言以提升效率的时代已经过了 现在如果要用组合语言提升速度 多半都是先做profiling找出效率的瓶颈 然後再小部分用组合语言加速 (反正把assembly嵌入C之中是很容易的事) : 推 Dopin:组语要写得结构化才会比较 OK 之後还有优化 203.70.65.28 06/08 : → Dopin:有些工具还颇好用的 以前在 TASM/MASM 时代常用的 203.70.65.28 06/08 : ※ 编辑: littleshan 来自: 140.112.244.211 (06/08 20:17) : 推 cooller:比如 icc 一定会对 HT 做最佳化啊 140.112.25.140 06/09 不一定 你的程式必须是multi-thread一起跑 才能得到HT的加速 但并不是所有的程式都可以multi-thread : → cooller:此外，现在人写的组语未必比 compiler 写的快 140.112.25.140 06/09 : → cooller:编译器是为了一般性，一定有一大堆不必要的东西 140.112.25.140 06/09 是的 -- --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.244.211 ※ 编辑: littleshan 来自: 140.112.244.211 (06/10 04:25) ※ 编辑: littleshan 来自: 140.112.244.211 (06/10 04:29) ※ 编辑: littleshan 来自: 140.112.244.211 (06/11 02:18)