TMA 总结

TMA 非常适合用于识别 CPU 性能瓶颈。理想情况下，我们希望看到退休（Retiring）指标达到 100%，尽管存在例外情况。Retiring 达到 100% 意味着 CPU 完全饱和，正在以全速处理指令。但这并不能说明这些指令的质量。一个程序可能在紧密循环中等待锁，这会显示出很高的 Retiring 指标，但实际上没有做任何有用的工作。

另一个可能看到 Retiring 指标很高但整体性能较慢的例子，是当程序存在一个未被向量化（vectorized）的热点时。你给处理器一个"轻松"的工作，让它运行简单的非向量化操作，但这是使用可用 CPU 资源的最优方式吗？当然不是。如果 CPU 在执行你的代码时没有问题，并不意味着性能无法提升。要注意这类情况，并记住 TMA 识别的是 CPU 性能瓶颈，而不是将其与程序的整体性能挂钩。在做必要的实验之后，你才能了解全貌。

虽然在玩具程序（toy program）上实现接近 100% 的退休是可能的，但真实世界的应用程序距此还很遥远。图 TMA_google 展示了 Google 数据中心工作负载以及若干 SPEC CPU2006¹³ 基准测试在 Intel Ivy Bridge 服务器处理器上的顶层 TMA 指标。可以看到，大多数数据中心工作负载的退休分类占比非常小。这意味着大多数数据中心工作负载将大量时间花费在各种瓶颈上。后端受限（BackendBound）是性能问题的主要来源。与 SPEC CPU2006 相比，前端受限（FrontendBound）对数据中心工作负载构成更大的问题，因为这些应用程序通常代码库庞大、局部性（locality）较差。最后，某些工作负载受分支预测错误的影响比其他工作负载更严重，例如 search2 和 445.gobmk。

请记住，随着架构师不断改进 CPU 设计，这些数字在其他 CPU 世代中可能会发生变化。对于不同的指令集架构（ISA）和编译器版本，数字也可能不同。

在继续之前，有几点最终思考……如本章开头所提到的，在代码存在严重性能缺陷时不建议使用 TMA，因为它很可能将你引向错误的方向——你会去调优糟糕的代码，而不是修复真正的高层性能问题，这只是在浪费时间。同样，要确保环境不会干扰性能剖析。例如，如果你在文件系统缓存（filesystem cache）被清空的情况下运行基准测试并进行 TMA 分析，它很可能显示应用程序受内存限制，而当文件系统缓存预热后，这实际上可能是错误的结论。

TMA 提供的工作负载特征描述（workload characterization）可以将潜在的优化范围扩展到源代码之外。例如，如果一个应用程序受内存带宽制约，且所有软件层面的加速方法都已用尽，那么通过升级内存子系统（使用更快的内存芯片）来提升性能是可能的。这说明利用 TMA 诊断性能瓶颈，可以为你在新硬件上的投入决策提供依据。

¹³. SPEC CPU 2006 - http://spec.org/cpu2006/. ↩