21. 寻找瓶颈(PPro，PII和PIII)

在这些处理器上作代码优化时，分析瓶颈的原因很重要。

当有一个要害的瓶颈存在时，花时间优化不是瓶颈的方面是没有意义的。

如果你估计到指令cache失效，那么你应该重组代码，将用得最多的部分放在一起。

如果你估计有很多次数据cache失效，那么不要再想其它事情了，集中精力于重组数据减少cache失效的次数（第7章），且要避免在读数据cache失效后存在一个长的依赖环（第20章）。

如果你有很多除法，那么试着减少它们（第27.2节），且保证处理器在做除法期间有其它事情做。

依赖环有妨碍乱序执行的倾向（第20章），试着打破长的依赖环，尤其是其中包括像乘法、除法和浮点指令这样的慢指令的时候。

如果你有许多跳转、调用、或返回，尤其是有大量不大好预测的转移指令时，试着避免一些，可能的话用条件传输代替条件跳转，用宏代替小的过程（第22.3节）。

如果你混用了不同尺寸的数据（8，16和32位），那么留意部分延迟。
如果用了PUSHF或LAHF指令，那么留意部分标志延迟。 避免在移位或循环移位数大于1的指令后测试标志位（第19章）。

如果你以一个时钟3条微码的吞吐量为目标，那么要注意取指令和指令解码可能的延迟（第14章和第15章），特别是在小循环中。

一个时钟周期最多读2个永久寄存器的限制可能会使一个时钟的微码吞吐量减为3条以下（第16.2节）。

如果你经常在寄存器写操作的4个多时钟以后读该寄存器，这种限制可能会发生。 比如，你经常用指针对数据寻址，但很少修改这些指针。

一个时钟3条微码的吞吐量的必要条件是各个执行端口得到微码数不能超过总数的三分之一（第17章）。

引退站可以在一个时钟处理3条微码，但对于处理发生的跳转指令不是很高效（第18章）。