这是一道综合论述trace cache和SMT的答题
我搜集资料学习了，文中给出了一些参考资料
2. Trends in Microarchitectural Techniques
Computer architects areconstantly debating the value of different microarchitectural techniques, andtechniques that were considered very important in one generation are sometimesdiscarded in the next generation. Two techniques, trace caches and simultaneousmultithreading (or hyperthreading) that were considered to be very importantfor a previous-generation microarchitecture (e.g., the Intel Pentium IV) werenot considered desirable in a more recent microarchitecture (e.g, the IntelCore 2).
Put yourselves in theshoes of the chief architect of a contemporary microarchitecture.
(a)Argue why a trace cacheis a good choice.
(b)Argue why a trace cacheis a poor choice.
(c)Argue why simultaneousmultithreading is a good choice.
(d)Argue why simultaneousmultithreading is a poor choice.
Answer：
Q1~2：
有关Trace Cache的表述，基本是来自
《http://memcache.drivehq.com/memparam/Bench/Other/TraceCache.htm》，可以直接参考，我做了简单综述。而在张晨曦和胡伟武的书中对这部分介绍很少。
o Trace Cache的定义：trace cache中包含的是由分支预测展开的指令，而不是普通cache中的静态指令。而trace cache中的分支预测是否正确需要在取到该指令才能确认，即不能保证trace中就是我们所需要的指令，但分支预测准确率还是蛮高的，所以这是一个很有吸引力的想法。
o Trace Cache提出的背景：
n 商业竞争：
Trace Cache其实也是非常有创意的。由于AMD推出了Victim Cache，形成强力竞争，Intel必须要做出主频非常高的CPU来。而PIII的主频极限在1GHz左右，是不可能和AMD的Athlon长久僵持下去的。所以Intel开发的P4必须要达到非常高的可以吓人的主频。AMD做了一件惊天动地的事，就是做出了Thunderbird核心的Athlon，不仅各种测试指标比PIII好，而且主频还比PIII高。Intel措手不及，仓促推出PIII 1.13GHz，但是PIII核心毕竟能力有限，不得不尽数收回，Intel可谓吃了大亏。在这种情况下，Intel必须推出一款至少看起来非常快的CPU来和AMD竞争。而且，Intel的时间非常有限。由于当时CPU主频已经跨越1GHz，根据摩尔率，2～3GHz的CPU出现的时间已经不远了，Intel为了在主频上取得竞争优势，就必须瞄准2～5GHz这样的档次。
n 技术背景：
要提高主频，CPU的流水线深度就必须增加。事实上，由于x86指令集的复杂特性，x86系列CPU的流水线中相当一部分的深度（大约有一半）是耗费在指令译码上的。所有这些问题在顺序执行程序中都不成为问题，流水线就是为这设计的。但是条件转移指令却造成了大麻烦。由于条件转移指令有2个分支，而究竟应该执行哪个分支，却要等条件转移指令执行完以后才能知道。而在指令进入流水线到得到执行结果之间有很多个周期，在这期间用哪个分支的指令去填满流水线就成了问题。、另外，由于条件转移指令的出现概率很大（静态10％，动态15％，相当于每执行6～7条指令就有一条条件转移），使这个问题必须解决，才能使流水线有实际的性能提升。而事实上，这个问题也有相对较好的解决方案，就是分支预测。虽然可以用分支预测，但是毕竟只是预测，不可能做到100％的准确。对分支指令来说，预测的准确率达到一个程度之后就很难再提高了。当然，分支预测失败在流水线浅的CPU上是问题不大的，因为在得出结果前没有多少指令进入流水线，刷新一下也不费事。但P4就不同了，其20级流水线，且大部分是在指令译码部分，一次刷新就把所有的性能都刷掉了。所以，分支预测的问题还要用更强有力的手段来处理。
n 计算分析：
为了解决这个问题，还是要先看一下影响性能的各个因素。我们关心的不是直接的分支预测准确率这样的指标，而是实际的程序执行速度。前面已经讨论过，流水线可以很容易对付顺序执行，主要的问题是分支。所以，我们看一下在有分支预测功能的CPU上，分支指令的“视”执行速度公式：
ExecTime = PredictTime + FailRate×FailPenalty
其中ExecTime表示平均的执行速度，PredictTime表示在预测成功情况下分支指令的执行速度，FailRate是预测失败的概率，FailPenalty是分支预测失败时需要多少时间恢复流水线。可见，右边的3个量任意一个的减少都可以提升性能。
1. 首先看FailRate，前面已经说过FailRate在达到一定程度后很难再减少，所以其提升能力有限，不过Intel还是在这方面做了一些工作，包括更深的BTB等等。
2. 当然，光靠这一点是不能解决问题的，还必须要有其它的措施。另外2个参数，PredictTime在PIII上是1，事实上可以通过一些技术减少到0，但是不可能再少了，而且其减少的量也不大。后面我们也要分析，Intel的Trace Cache可以把这个参数减少到0。
3. 前2个参数的改进都无法达到目的，就只剩下最后一个参数了。我们前面说过，流水线加深会导致分支预测失败的附加开销增加，也就是FailPenalty增加。所以，最直接的优化方法是减少流水线深度。但是，要提高主频，就必须要加深流水线深度。这似乎是一个死循环。其实不然，要解开这个死节也是有一些办法的。一种“傻、大、粗”的方法是把2个可能的分支都放到流水线中执行，等分支确定以后，只要把不该执行的一半去除就可以了，另一半是正确的。对超标量CPU来说，这是可以实现的，而且不复杂（似乎IBM的PowerPC是采用这样的方案：IBM一贯的风格就是傻大粗，不过没有查阅过详细的资料，不能确定）。这样的实现缺点也是显然的，2个分支都要进入CPU，浪费的资源也比较多。
n Great Idea：
要解决问题首先就要研究问题。对x86指令集，译码需要的时间是很长的，流水线的大部分工作是进行指令译码。如果我们可以把这部分时间坎掉，其实流水线就不深了。所以，在执行时不需要指令译码是最理想的方案。执行时不译码并不等于是要求直接执行x86指令，事实上这样的要求是不可能在高速CPU中采用的。要解决这个问题还要看程序的特点。对任何程序，几乎都可以说其执行时间绝大部分是在循环体内的。因为现在的CPU非常快，即使只1秒时间，也可以执行1G条左右的指令，如果没有循环，最简单的单字节指令也要有1GB大小，而我们的可执行文件大的也不过1～2MB，也就是说程序中平均每条指令要执行1000～1000000次。这是一个非常好的特点：如果这条指令要执行1000次，那我们只译码一次，而执行它1000次，则把一次译码的时间分摊到1000次执行，基本上可以忽略，所以这种方案可以叫做“不译码”的。
这样，处理方法就出来了：我们先把整个程序都译码放到一个缓冲区中，然后在这个缓冲区上执行，由于此时分支的2个后继都在缓冲区中，即使发生预测失败，也只需要刷新流水线的执行部件内的错误指令，译码部件的长流水线就从FailPenalty中砍调了，从而大大降低了FailPenalty。
上面所说的要把整个程序都译码放到一个缓冲区中其实是没有必要的，在这方面，传统的缓存理论可以解决这个问题，所以，我们要做的是一个缓冲译码后的指令的缓存，在这个缓存的读端口上加一个译码部件就可以了，其缓冲的内容是虚的。这就是Intel的Trace Cache。
o Trace Cache提出的优点：
1. Trace Cache是0周期条件转移。因为分支预测成功时，将从Trace Cache中加载译码后的指令（Intel称作微操作，uOP），这些指令的译码被消除了，节约了时间，相当于分支指令没有用时间。而分支指令是很多的（15％），加上强有力的分支预测，对提高程序性能应该说是非常有帮助的。
2. Trace Cache可以消除指令预取对循环和函数起始地址的要求。由于指令预取总是在16字节边界，所以要充分利用指令预取的缓冲区，函数和循环的入口地址应该对齐到16字节边界。而Trace Cache中的微操作根本不需要译码，所以不存在指令预取缓冲区，也没有这个问题。
3. Trace Cache可以解决指令译码配对的问题。由于x86指令异常复杂，不可能同时集成多个全功能的指令译码部件，所以在PIII和Athlon中都对简单指令和复杂指令分别对待，这就要求指令按一定的模式出现，才能让所有的译码部件能够并行工作。而Trace Cache中的微操作不需要译码，自然不存在如何配对的问题。
o Trace Cache提出的不足：
译码后的微操作有一个特点，就是很长。PIII的微操作长度，按Intel的说法是72位，合9字节。在P4的Trace Cache中，我估计不会用这么长的微操作，必须进行压缩。但是，由于x86指令集有32位常数，要获得足够的执行效率，微操作中必须要能够放得下，所以微操作长度不能少于32。虽然可以象MIPS一样把常数分解成2个16位，但那样就会使微操作数量大大增加，执行部件的负担会增加很多。所以，我们不妨设P4的微操作长度为48（是否能压缩到这个长度还是个问题）位，合6字节。于是，12K的Trace Cache合12×6＝72KB！要知道Athlon的L1I-Cache才64KB，也就是说P4的Trace Cache消耗的晶体管数比Athlon的L1 I-Cache还要多了很多，其身材......是足够天使了。虽然Intel的电子技术先进，但也经不起这样的浪费啊，所以不得不砍去其它的一些部件，于是L1D-Cache由16KB砍成了8KB，MMX运算单元由2个砍成了1个，指令译码单元由3个砍成了1个，地址生成单元被砍没了，单周期、全流水的MMX/SSE运算单元被砍成了2周期、差不多不流水的了，L2的块大小由32字节砍成了128字节，再砍就不是CPU了！！所以，万般无赖之下，P4不得不开足了马力，功率直冲70瓦，大有赶超Athlon之势。
Q3~4：
有关同时多线程，即SMT技术，在张晨曦的书中有一节专门描述，而在胡的书中没找到。
我主要参考了如下的资料：
1、 张晨曦书的介绍；
2、 2002年的网页SMT将处理器带入新时代?：（http://www2.ccw.com.cn/02/0236/b/0236b18_1.asp）
3、 百度文库 同时多线程介绍 http://wenku.baidu.com/view/fa3c70da6f1aff00bed51e2a.html
4、 豆丁文库SMT读书笔记 http://www.docin.com/p-92506524.html；
o 背景：别让发射槽闲着
超标量技术和多线程技术的结合，产生了SMT，从而让处理器资源得到充分利用，也让处理器性能得到提高。在过去的20多年中，为了提高性能，处理器结构不断发生变化。最简单的标量处理器在一个时钟周期内最多发射一条指令，而指令间又存在着某种相关性。这些相关性表现在三个方面：一是由于使用同一功能部件造成的结构相关；二是访问同一寄存器或同一存储器单元而产生的数据相关；三是由于转移指令所造成的控制相关。因此，这种结构的IPC（instruction per cycle）实际上小于1。
为了提高IPC，产生了多发射技术，其中最常用的就是“超标量”。这类处理器每个时钟周期可以给不同的功能部件发射多条指令。为了减少指令间的相关性对性能产生的不良影响，在超标量处理器中，采用了乱序执行、寄存器重命名和分支预测技术。但仍然无法完全消除相关，造成在一个时钟周期内可能没有足够的可发射指令来填满所有的发射槽，有的时钟周期内甚至可能出现没有指令可以发射的情况，空闲的发射槽将被白白浪费。在多处理机系统中，远程访问延迟所造成的性能损失就更大了。因此一个4发射的处理器的IPC一般只略大于2，而且如不采用其他技术，对于一个m发射的超标量处理器来说，当m > 4时，随着m的增加，IPC的增幅将迅速降低。为此，必须通过其他方式来提高处理器的性能。
o 提出：
多线程处理器便是一个很好的尝试。多线程处理器对线程的调度与传统意义上由操作系统负责的线程调度是有区别的。它完全由处理器硬件负责线程间的切换。由于采用了大量的硬件支持，线程的切换甚至可以在一个时钟周期内完成。在一个细粒度多线程处理器中，每个时钟周期都从一个不同的线程中选择指令，并发射到相应的功能部件中。由于不同线程的指令间不存在相关性，因此可以保证每个时钟周期都有指令可以发射。即使某条指令有很长的访存延迟，多个线程的切换运行也可以有效地隐藏延迟。但是，在采用多线程技术的超标量处理器中，同一时钟周期内执行的还是同一线程的指令，仍然存在相关性，因此仍然有一些发射槽被浪费。那么还有没有更好的处理器结构呢？当然有！那就是同时多线程。
同时多线程技术是超标量技术与多线程技术的完美结合。它允许指令发射部件每一时钟周期都可以从多个线程中选择多条不相关的指令，发射到相应的功能部件中去执行。同时多线程处理器完全有能力每个时钟周期都填满所有的发射槽，而不产生任何浪费。由此可以看出，多线程处理器在性能方面的优势是不言而喻的。
o SMT的优势
SMT无疑是处理器结构方面一次不小的突破。在其他处理器结构中，许多想尽办法也无法解决的难题，在同时多线程结构中却很容易解决。这一技术的优势就体现在它具备解决影响处理器性能的诸多难题的能力，如减少相关性。
(1) 减少结构相关对性能的影响
当某条指令由于使用的功能部件被前面的指令所占用而无法执行时，这两条指令就发生了功能部件冲突，我们称这样的指令之间存在结构相关性。超标量处理器中使用了计分板(scoreboard)或Tomasulo机制来支持指令的乱序执行。其原理是：当某条指令由于功能部件冲突而无法执行时，其后继的无结构相关的指令可以先被执行。
同时多线程处理器不但支持乱序执行，而且其采用的同时从多个不同线程中选择指令的方式，还大大减少了指令间出现功能部件冲突的概率，也就进一步减少了结构相关产生的危害。
(2) 减少逻辑相关对性能的影响
为了消除寄存器的“读后写”和“写后写”相关，也就是所谓的“伪相关”，超标量处理器的寄存器文件中物理寄存器数目都大于程序员所能看到的逻辑寄存器数，并采取了相应的“寄存器重命名”策略。但对于“写后读”相关，也就是所谓的“真相关”，超标量处理器却无法解决。
在同时多线程处理器中，为了在线程切换过程中快速保存和恢复现场，每个线程都配备了独立的寄存器文件，只要选择不同线程的指令就不存在寄存器的“写后读”相关。当再次调度到同一线程时，即使下一条指令与前面的指令存在“写后读”相关，前面的指令也已经执行完毕，相关性危害也就不存在了。同时，对于每个线程，同样采用寄存器重命名技术来消除伪相关。因此，同时多线程处理器有能力消除各种由于寄存器相关而产生的危害。
对于访问同一存储器单元的指令，传统的方式是通过编译器优化，将前一条指令的前驱指令或后一条指令的后继指令插入到这两条指令中间，拉大这两条指令的间距，以期减少此类相关引起的危害。但编译器找不到合适的插入指令的情况并不少见。而同时多线程处理器可以通过切换线程的方式，近一步增大这类指令的间隔，减少访存地址相关的危害。
(3) 减少控制相关对性能的影响
当执行到转移指令时，只有等到它执行完毕才能准确得知后继指令的地址。如果不采取措施，在等待转移指令执行结果的这段时间里，后继指令将无法执行，造成指令流水线的闲置。在超标量处理器中通常采用转移预测技术，预测可能的转移方向，并按照这一方向继续执行。当转移地址确定后，如果与预测方向相同，则确认推测执行的结果;如果与预测方向不同，则在转移指令之后被发射的所有指令将作废，并从正确的转移地址处开始执行。因此，转移预测的正确率就显得非常重要了。现在的转移预测技术的正确率可以达到85%～95%，对于特定作业甚至可以高达99%以上。但随着处理器一个时钟周期内发射指令条数和指令流水线级数的增加，处理器中处于in-flighting状态的指令数目也迅速增加。一旦预测失败，作废的指令条数也就增加了。
同时多线程技术的出现，为减少预测失败提供了一条新的途径。它将分支的两个转移方向映射到不同的线程中，同时执行，等转移地址确定后，从两个线程中选取正确的一个继续执行，错误的线程将被中止。虽然废止错误的线程会损失一些效率，但由于存在多个同时运行的线程，因此不会出现所有in-flighting指令都被作废的情况。虽然单独使用这一技术来处理转移指令，效率并不高，但是将这一方法与传统的转移预测技术相结合，则会进一步减少控制相关所产生的危害。
(4) 隐藏远程访问和同步等待延迟
在大规模并行计算机系统，特别是拥有数千个处理器节点的DSP系统（分布共享处理器系统）中，处理器访问远程存储空间的延迟可以高达200多个时钟周期。同样在如此大的系统中，多个节点间的同步等待延迟也不容忽视。传统处理器通过忙等待（busy waiting），或一个耗时很长的操作系统级线程切换来处理此类情况，随着高性能计算对系统效率要求的不断提高，这样的处理方式已经不能满足要求了。
操作系统级线程切换所消耗的时间开销可能比访存延迟造成的损失还要大。而同时多线程处理器中由硬件支持的快速线程切换机制，几乎可以做到“零时间开销”。因此，同时多线程处理器可以通过线程切换，在一个任务进行远程访问和同步等待过程中，运行其他任务的线程，将延迟有效地隐藏起来。
o SMT的不足：
(1) 保存多线程的现场需要设置更大的寄存器组
(2) 在关键路径上，由于需要更多的计算开销，可能会影响时钟周期
(3) 需要保证由于并发执行多个线程带来的Cache冲突和TLB冲突不会导致明显的性能下降
870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
