很多时候，一个架构师选择Load/StoreSpeculation的终极方法是掷硬币，只是在用一只很有技巧的手去投掷这个硬币。这些猜测是无限追求完美的人群，在屈服于最终的命运安排之后使用的赌徒方式。有人质疑这种掷硬币和闭着眼睛猜有什么区别。闭着眼睛猜确实是一种办法，只是当你睁开双眼发现迷失后，知道归时之路。
Load/StoreSpeculation的结果可能正确，也可能错误。如果最终结果是正确的，是一次成功的投机，如果错误会带来一定的惩罚。如果一次投机将导致不可收拾的系统惩罚，其最终结果不如不进行这些猜测。片面追求投机而忽略惩罚只是莽夫所为。合理的预测执行与失败后可以承担的惩罚是一个大的权衡。投机是人类与生俱来的。在投机的成功率越高，相应的惩罚越低时，这个天性就更加容易暴露。
Speculation策略需要在成功率和惩罚间进行取舍。让我无限制的悔棋，从理论上说我可以战胜一切对手。只是这个对手如果是李昌镐，至死我也下不完一盘棋，所以我将目标设为悔棋十步，去挑战那位每次只能胜我一目半目的邻居。采用十步悔棋规则后，那位邻居每次战至中盘，即与我签订城下之盟。
溯本求源，我们重新讨论为什么会出现Load/Store Speculation。为简化起见，我们仅在此讨论Load Speculation而忽略Store Speculation。在现代处理器系统中，存储器Load请求所需的Latency相对于CPU的主频在不断提高，使得存储器瓶颈问题更加突出一些。使用Load Speculation的主要原因是为了掩盖这些Load Latency，尽量的让执行延时较长的存储器读指令笨鸟先飞早入林。如何决定让那只笨鸟先飞是一个较为复杂的预测过程。在讲述这些预测之前，我们首先讨论这些预测的基本实现机制和预测失败的后继处理方法。
我们简单回顾ConfidenceCounter机制，Confidence Counter是一种常用的，判断是否应该进行预测的加权处理方式。除了Load/Store Speculation实现之外，Confidence Counter也广泛应用于Branch Prediction领域，是一种已经得到证明的，行之有效的方式。其实现机制与N-bit Saturating Counter(BimodalPredictor)类似。Confidence Counter由Saturation，Predict Threshold，Misprediction Penalty和Increment for Correct Prediction四个参数[14][15]组成。
我们以{31(Saturation),30(Threshold), 15(Penalty), 1(Increment)}为例简要说明Confidence Counter的使用方法。假设在一个应用中，Confidence Counter的初值为29，此时指令流水线将不会进行Load Speculation操作。如果指令流水线发现执行的最终结果为真时，Confidence Counter将加1(Increment)；当Confidence Counter的值等于或者超过Threshold时，指令流水线开始进行Load Speculation；如果Confidence Counter的值为31(Saturation)时，结果为真时也保持不变；如果预测失败后，Confidence Counter将一次减去15(Penalty)，直到逐步加1到达Threshold后才能触发Load Speculation。
在BranchPrediction中也使用了Confidence Counter机制。假设在一个分支预测系统中，使用2-b Confidence Counter，而且Strongly Taken, Weekly Taken, Weekly notTaken和Strongly not Taken这状态位为3，2，1和0时，Taken路径使用的Confidence Counter为{3, 2, 1, 1}，Not Taken路径使用的Confidence Counter为{0, 1, -1, -1}。
大多数LoadPrediction算法使用Confidence Counter作为是否进行预测的基本分析工具。在Load Speculation失败后，指令流水线大多使用两种机制进行恢复操作，分别为Squash和Reexecution机制[14][15]。
Squash指当某条Load指令预测失败后，将ROB中在其之后的指令抛弃，并重新从指令Cache中Fetch指令。这种方式与BTB预测失败后采取的方式类似。Reexecution指当某条Load指令预测失败后，仅仅重新执行与此指令直接或者间接相关的指令。
从直觉上看，采用Reexecution比Squash机制的效率高出许多。但是我们依然不能依次得出Reexecution一定优于Squash机制的结论。在体系结构设计中，更多要考虑的依然是权衡。Reexecution机制需要使用更多的逻辑和数据缓冲也是不争的事实。
在已知的指令流水线设计中，LoadSpeculation主要有四种算法实现，分别是Dependency Prediction，Address Prediction，Value Prediction和Memory Renaming。这些Prediction的实现机理依然是猜测，并借用Confidence Counter机制和以往的经验尝试。Load Speculation与Brach Prediction的实现有类似之处，本质上是一个机器的自学习过程。
其中DependencePrediction算法的实现机制较为简单。对于现代处理器，能够精确判断存储器读写指令间的依赖关系至关重要。在一些支持读写指令的乱序执行的微架构中，在这些处理器中通常使用LSQ支持多条存储器读写执行的并发执行，以提高指令执行的并行度。为确保正确处理读写指令间依赖关系，万无一失的方法是每一条Load指令在乱序发射之前，遍历在LSQ中的Store指令，确保与其不发生依赖关系。如果在LSQ没有发现依赖关系，这条Load指令才可以被乱序执行。
采用这种方法虽然保证了存储器读写指令的正确执行，却带来了较大的系统延时。Store指令在执行到一定阶段时，Load指令才能精确地判断这种相关性，在LSQ中的Store指令并不都是准备就绪的。Dependence Prediction算法就是为了取消这类等待延时的一种方法。该算法有Blind Prediction，Wait Dependency Predictor和Store Sets等实现策略。
最简单的策略莫过于BlindPrediction。所谓Blind Prediction，指Load指令仅检查在LSQ中准备就绪的Store指令，如果没有发生相关性，即可提前执行，如果在LSQ发现了Store Alias，则直接从Store Queue中获取数据。对于没有就绪的Store指令，Blind Prediction认为不存在相关性。如果最后的执行结果证明确实两者之间存在相关性，被错误执行的Load指令，将采用Squash或者Reexecution方式恢复。
Alpha 21264采用了Wait Dependency Predictor策略[18]进行Load Speculation。其实现机制是在指令Cache中的每一条指令加入一个Wait位，当Load指令的EA计算完毕后，而且相应的Wait位为0时，这条Load指令可以Speculation，否则需要等待。当发生预测失败后，相应的Wait位需要置1以避免进一步的预测失败。全部Wait位在100,000个Cycle后将自动清零，以避免因为多次预测失败造成很多Wait位都置1的情况发生。当发生指令Cache Miss的时候，Wait位将清零。
Store Set是另一种Dependence Prediction实现策略。其实现机制是使用Store Set ID连接对同一个地址的存储器读写访问，并将这些ID存放在SSIT(Store Set Identifier Table)中。在存储器读写指令预取之后，使用PC作为Index索引SSIT后获得对应的ID，这个ID指向另一张表LFST(Last Fetched Store Table)。在LFST中记录了已经访问相同地址的Store指令，并使用这种方法判断读写指令之间的依赖关系，没有发现依赖关系的Load指令，将可以进行后续的Speculation。
以上这几种策略的相同点是利用读写指令间存在的依赖关系，提高Load Prediction的预测成功率。使用这类方法时，存储器读写指令都需要获得EA后，才能进行进行相应的预测。采用Address Prediction算法更加Aggressive一些，这类算法的本质是在存储器读写指令计算EA之前，预测这个EA的值，从而实现计算EA与实际访问存储器操作的并行执行。处于Critical Patch的存储器访问操作，其EA不但可以预测，而且成功率很高。
AddressPrediction算法的常用实现策略有LVP(Last Value Prediction)，Stride和Context。使用LVP策略时，下一次存储器访问的预测地址是上一次刚刚访问过的地址；使用Stride策略时，预测地址是上一次刚刚访问过的地址加上某个偏移；Context策略更具智慧，采用这一策略时，可以利用存储器访问过的历史信息VHT，形成一个Pattern，之后计算出一个合适的值索引另一张表VPT，以获得策略的地址，这一方法与BTB中常用的gshare机制类似。
对于不同的应用，LVP，Stride和Context策略的预测成功率并不相同，Context策略貌似最优，但依然存在一些应用使用LVP和Stride策略预测成功率更高一些。因此在一个微架构的具体实现中可以使用不同权值的Confidence Counter混合使用LVP，Stride和Context策略，以获得更优的结果。
ValuePrediction算法与Address Prediction算法的实现策略类似。其不同之处是一个预测的是将要使用的地址，一个预测的是最终数据。显然Value Prediction算法更加Aggressive一些。Value Prediction与Address Prediction的实现策略较为一致，也使用了LVP，Stride和Context策略，策略的实现方法也几乎一致。
ValuePrediction算法并不能避免存储器读操作最终穿越Cache Hierarchy，并不能避免任何Bus Traffic的出现。指令流水在获得数据之后，需要进行Check-Load操作，确定是否发生了Misprediction，但是采用这种算法使得指令流水可以更早的获得Load操作的结果，从而使其后的指令可以在猜测中继续执行。
在存储器瓶颈愈发严重的今天，ValuePrediction算法曾被多次提及。Andy Glew有一个非常Crazy非常大胆的想法，他设想了一个可以容纳几千条并发执行的单发射的微架构，使用各类耸人听闻的技术，包括Value Prediction进一步优化MLP(Memory-Level Parallelism)[22]。以个人浅见，使用一个更大规模，比如几百兆的最后一级Cache也比这些想法有实现的可能。当芯片制作工艺到达10nm时，处理器系统包含一个几百兆的EDRAM应该不是什么难事。可能在14nm工艺之下就可以实现这样容量的LLC。
最后需要说明的是MemoryRenaming算法。研究发现Store和Load指令对存储器的访问可以由硬件精确预测[19][21]，使用Confidence Counter即可方便地实现这一目标。当Store和Load指令建立了确定的关系之后，Load指令不必每一次都从存储器子系统中获得数据，因为Store指令可以将数据直接送至建立映射关系的Load指令。这一方法相当于指令流水将已经与Store指令确立关系的Load指令的存储器器访问，转化为对LSQ进行访问，这也是Renaming的由来。Memory Renaming技术也有一些具体的实现策略，而且这些策略依然可以混合使用。在此不再一一述说。
在一个微架构中可以同时使用这四大类算法，也可以只使用部分。在这四大类算法中，都有各自的实现策略，这些策略可以混合使用。Confidence Counter使用的不同参数也决定了预测的成功率。预测失败的恢复手段还有两种选择。
这使得在一个Load/StoreSpeculation设计中有非常多的选择。在其他领域的实现中，系统设计者也会遇到许多选择。过多的选择经常令人无所适从。系统设计者很难从公说公有理婆说婆有理的，甚至有意无意去误导的各类量化分析结果中得出精确结论，做出最正确的选择。他们最后的选择是去掷硬币[1]。
“掷硬币”是面对过多选择的无奈。一个是非的结果很难只有是与非这样简单。有些选择是单纯的也是幸运得几乎不存在的，他们一次就认定了是与非。更多的是经历了大是大非，在是是非非中反复后的是与非。是可以倾听自己心跳声的人绞尽最后一滴脑汁后的感觉。
许多设计都存在这样的是非，即便这些设计出自最权威系统架构师之手。这些不可知引发了一个讨论，是否有哪怕是特定应用之下，最优微架构的存在。我们很难确定在一个具体的实现中，O(n×Log2n)一定优于O(N2)，在一个实现中N是有限的，不是理论上的无限，而且不同的算法使用的实现时间并不相同。
即便使用相同的算法，具体实现依然有优劣之分。我有些机会体验过这些糟糕的实现。这些实现不仅出现在入门级别的公司，也出现在国内顶级的公司。最初对这些实现是惊讶的，在习以为常后只剩下是无奈。而后发现就是这些实现战胜了由常青藤组成的个体，团队，帝国。明白这些人更加懂得，什么是权衡，什么是掣肘，什么是地处中国的不得已。
这一切超越了技术层面，或者说技术层面的权衡源自于此。另一方面，我想说这样获得的成功很难让整个世界信服。有过资治通鉴的国家在人与人的争斗，人与人的相互排挤与贬低上，哪怕是少费一点点时间，整个世界也会因此更加精彩。
有些仿佛只能出现在金庸小说中称着洪教主福如东海，寿比南山这样的言语与行为，也确确实实的发生着。黑压压着一片的人群，很多行为仿佛自己是这个星球的最后一代，疯狂着掠夺。任何美丽在此面前都荡然无存。
完成了第一章的书写后，我几乎准备放弃。不是因为我已经写完了我想书写的内容，而是不知道如何继续。简单罗列好目录后，能够约定的只有终稿的日期，写到那时便是结束，没有刻意的规划。
368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
