TMA 总结

TMA 非常适合识别 CPU 性能瓶颈。理想情况下，当我们在应用程序上运行它时，我们希望看到“Retiring”指标达到 100%。尽管存在例外。“Retiring”指标达到 100% 意味着 CPU 已满负荷工作，并且以全速处理指令。但这并不能说明这些指令的质量。程序可以在紧密循环中等待锁，这将显示高“Retiring”指标，但不会做任何有用的工作。

另一个您可能看到高“Retiring”值但整体性能较慢的例子是程序存在未向量化的热点。您通过让处理器运行简单非向量化操作来让它“轻松”，但这真的是利用可用 CPU 资源的最佳方式吗？当然不是。如果 CPU 没有执行代码的问题，并不意味着性能无法提高。注意这种情况，并记住 TMA 识别 CPU 性能瓶颈，但不会将其与程序性能相关联。您一旦进行必要的实验就会发现这一点。

虽然在玩具程序上实现“Retiring”接近 100% 是可能的，但现实世界的应用程序远不能达到。图 @fig:TMA_google 展示了 Google 数据中心工作负载的顶级 TMA 指标以及在 Intel 的 IvyBridge 服务器处理器上运行的几个 SPEC CPU2006: http://spec.org/cpu2006/¹³ 基准测试。我们可以看到，大多数数据中心工作负载在“Retiring”桶中所占的比例非常小。这意味着大多数数据中心工作负载都会花时间停滞在各种瓶颈上。“BackendBound”是性能问题的首要来源。“FrontendBound”类别对于数据中心工作负载来说比 SPEC2006 更重要，因为这些应用程序通常具有庞大的代码库。最后，一些工作负载比其他工作负载更易受分支预测错误的影响，例如“search2”和“445.gobmk”。

请记住，随着架构师不断尝试改进 CPU 设计，这些数字可能会随着其 CPU 而改变。这些数字也可能会随着其他指令集架构 (ISA) 和编译器版本的改变而改变。

在我们继续讨论之前，还有一些最后的思考...... 不建议在性能存在重大缺陷的代码上使用 TMA，因为它可能会将您引入错误的方向，并且您将修复真正的性能问题，而不是调整糟糕的代码，这只会浪费时间。同样，确保环境不会妨碍分析。例如，如果您丢弃文件系统缓存并在 TMA 下运行基准测试，它可能会显示您的应用程序受到内存限制，而实际上，当文件系统缓存预热时，这可能是错误的。

TMA 提供的工作负载特征描述可以将潜在优化的范围扩展到源代码之外。例如，如果应用程序受内存带宽限制，并且已经用尽所有可能的软件层面加速方法，那么可以通过升级内存子系统以使用更快的内存芯片来提高性能。这说明了如何使用 TMA 诊断性能瓶颈来支持您决定在新硬件上花钱。

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