Intel64及IA-32架构优化指南第8章多核与超线程技术——8.5 系统总线优化

8.5 系统总线优化

系统总线服务向总线代理（比如，逻辑处理器）请求来从存储器子系统获取数据或代码。因从存储器获取数据交通而产生的性能影响依赖于工作负载的特征，以及软件对存储器访问优化的程度，在软件代码中实现的位置增强。在附录A中讨论了描绘一个工作负载的存储器交通的一些技术。位置增强的优化准则也在3.6.10小节中讨论。

在第3章和第7章中所讨论的技术在总线系统服务一单个线程的环境中的一个平台上获得应用程序性能的利益。在一个多线程环境中，总线系统一般服务更多的逻辑处理器，其中每一个逻辑处理器都能独立地发布总线请求。因而，位置增强、保存总线带宽、减少大跨度Cache失败延迟的技术会对处理器性能增幅具有很大影响。

8.5.1 保存总线带宽

在一个多线程环境中，总线带宽可以被来自多个总线代理（这些代理可以是若干逻辑处理器以及/或若干处理器核心）所发起的存储器交通所共享。维持总线带宽可以提升处理器性能增益。同时，如果有严重的大跨度Cache失败，那么有效的总线带宽一般会下降。减少大跨度Cache失败（或减少DTLB失败）的数量将减缓由于大跨度的Cache失败而引起的带宽减少问题。

保存可用的总线命令带宽的一个方法是提升代码和数据的位置性。提升数据的位置性减少了Cache行逐出和请求取数据的次数。这个技术也减少了从系统存储器取指令的次数。

用户/源代码编写规则26：提升数据和代码的位置性来保存总线命令带宽。

使用支持剖析器指导优化的一个编译器可以通过将频繁使用的代码路径保持在Cache中来提升代码位置性。这减少了取指令。循环块也能增强数据位置性。其它位置增强技术也可应用于一个多线程环境来保存总线带宽（见7.6小节）。

因为系统总线在许多总线代理之间共享（逻辑处理器或处理器核心），所以软件调整应该识别出总线趋于饱和的征兆。一种有用的技术是检查总线读交通的队列深度（见附录A.2.1.3）。当总线队列深度为高时，位置增强提升了Cache利用，将比起其它技术，诸如插入更多软件预取或用叠交的总线读来屏蔽存储器延迟，能获得更多的性能增益。对于软件在总线饱和以下进行操作的一个大概的工作准则是检查总线读队列深度是要注意在5以下。

某些MP和工作站平台可以有一个提供两条系统总线的芯片组，每条总线服务一个或多个物理处理器。在以上所描述的保存总线带宽的准则也应用于每个总线域。

8.5.2 理解总线和Cache交互

当并行代码段所包含的数据集，导致整个工作集超出L2 Cache并且/或消耗的带宽超出总线容能时，就得小心了。在一个Intel Core Duo处理器上，如果只有一个线程在使用L2 Cache以及/或总线，那么它被期望获得Cache和总线系统的最大利益，因为另一个核心不与第一个线程的运行进行交互。然而，如果两个线程并发使用L2 Cache，那么如果下列其中一个条件为真的话，那么就会有性能下降：

●  这两个线程所绑定的工作集比L2 Cache大小更大。

●  这两个线程所绑定的总线使用比总线容能更大。

●  这两个线程对L2 Cache中同一个数据集都有大量的访问，并且至少其中有一个线程对此Cache行进行写。

为了避免这些缺陷，多线程软件应该设法审查并行模式，在这些模式下，只有一个线程一次访问L2 Cache，或者对L2 Cache和总线的使用不超过它们的容能上限。

8.5.3 避免过度地软件预取

奔腾4和Intel Xeon处理器具有一个自动的硬件预取器。它可以将数据和指令基于先前引用模式带到统一的L2 Cache中。在大部分情况下，硬件预取器可以减少系统存储器延迟而不需要软件预取那种显式的干涉。它对于调整代码中的数据访问模式以利用自动硬件预取器的特征来提升位置性或屏蔽存储器延迟也是更可取的。基于Intel Core微架构的处理器也提供了几种先进的硬件预取机制。能够利用更早时代的硬件预取机制的数据访问模式通常可以利用更近的硬件预取实现。

过度地或无差别地使用软件预取指令将不可避免地导致性能处罚。这是因为过度地或无差别地使用软件预取指令浪费了总线的命令和数据带宽。

使用软件预取延迟了硬件预取器开始取处理器核心所需要的数据。它也消耗了临界执行资源并且会导致执行拖延。在某些情况下，计算软件预取的冗余或消除而迁移到对硬件预取机制的更有效地使用将会硕果累累。使用软件预取指令的准则在第3章描述。使用自动硬件预取器的技术在第7章描述。

用户/源代码编写规则27：避免软件预取指令的过度使用并允许自动硬件预取器工作。过度的软件预取的使用会严重地且不必要地增加总线使用，若使用不当的话。

8.5.4 改进Cache失败的有效延迟

由于Cache失败而引起的系统存储器访问延迟受总线交通的影响。这是因为系统总线读请求必须与其它为总线事务的请求一起做仲裁。减少未决的总线事务的数量帮助改进有效的存储器访问延迟。

改进存储器读事务的有效延迟的一种技术是使用多个叠交的总线读来减少稀疏读的延迟。在几乎没有数据的位置性或当存储器读需要与其它总线事务做仲裁时的情况下，被分散的存储器读的有效延迟可以通过背靠背地发布多个存储器读来叠交多个未决的存储器读事务来获得改进。背靠背地总线读的平均延迟可能比与其它总线事务所散布的分散的读的平均延迟更小。这是因为只有第一次存储器读需要等待一个Cache失败所需要的整个延迟。

用户/源代码编写规则28：考虑使用叠交的多个背靠背的存储器读来提升有效的Cache失败延迟。

减少有效存储器延迟的另一种技术也是有可能的，如果能够调整数据访问模式，诸如导致相继Cache在最后层Cache中失败的访问跨度小于自动硬件预取器的触发器上限距离。见7.6.3小节。

用户/源代码编写规则29：考虑调整存储器引用的顺序，诸如最后层Cache的相继Cache失败的距离分布峰值到64个字节。

8.5.5 使用完整的写事务来达成更高的数据率

贯穿总线的写事务导致或使用完整的64字节的行大小或使用少于行大小来写到物理存储器。后者被称为部分写。一般，写到写回（WB）存储器地址是完整大小的，而写到写联合的（WC）或非可被cache的（UC）类型的存储器地址导致部分写。被cache的WB存储操作和WC存储操作都利用了一组六个WC缓存（64字节宽）来管理写事务的交通。当所有对到缓存的写完成之前，正竞争的交通关闭一个WC缓存时，这导致一系列的8字节部分总线事务，而不是一单次的64字节写事务。

用户/源代码编写规则30：使用完整的写事务来达成更高的数据吞吐。

多个频繁地对WC存储器的部分写可以使用一个软件写联合技术而被联合到完整大小的写，以从与WB存储交通竞争中将WC存储操作分开。为了实现软件写联合，对带有WC属性的存储器做不被cache的写，被写到一个小的、临时的缓存（WB类型），这个缓存适应于L1数据Cache。当临时的缓存满了时，应用程序将临时缓存的内容拷贝到最终的WC目的。

当部分写在总线上处理时，对系统存储器的有效数据率被减少到系统总线带宽的1/8。