我需要提高系统的吞吐量。
通常的优化周期已经完成，我们已经实现了 1.5 倍的吞吐量。
我现在开始怀疑是否可以利用 cachegrind 输出来提高系统的吞吐量。
有人可以指出我如何开始吗？
我的理解是我们需要确保最常用的数据应该保持足够小，以便它保留在 L1 缓存中，而下一组数据应该适合 L2。
这是我正在采取的正确方向吗？
问问题
4068 次
4 回答
6
确实，cachegrind 输出本身并没有提供太多关于如何优化代码的信息。人们需要知道如何解释它以及您所说的关于适合 L1 和 L2 的数据确实是正确的方向。
为了全面了解内存访问模式如何影响性能，我建议阅读 GNU libc 维护者 Ulrich Drepper 撰写的优秀论文“What Every Programmer Should Know About Memory”。
于 2009-11-12T19:20:04.583 回答
3
如果您在解析 cachegrind 输出时遇到问题，请查看 KCacheGrind（它应该在您选择的发行版中可用）。我使用它并发现它很有帮助。
于 2009-11-12T17:59:15.247 回答
2
1.5 倍是一个不错的加速。这意味着你发现了一些你可以摆脱的东西，花费了 33% 的时间。我敢打赌，你可以做更多的事情，甚至在你处理数据内存缓存等低级问题之前。这是一个例子。基本上，您可能会遇到以前并不大的其他性能问题（以及加速的机会），比如 25% 的人说。嗯，随着 1.5 倍的加速，这 25% 现在是 37.5%，所以它比以前“更有价值”了。通常，此类问题的形式是某些堆栈中的函数调用请求工作，一旦您知道它的成本是多少，您可能会认为这不是完全必要的。由于 kcachegrind 并没有真正确定这些，您可能没有意识到这是一个问题。
于 2009-11-19T14:18:01.410 回答
2
根据Cachegrind文档，cachegrind 提供给您的详细信息是代码给定部分的缓存未命中数。您需要了解缓存如何在您的目标架构上工作，以便您知道如何修复代码。实际上，这意味着使数据更小或更改某些数据的访问模式，以使缓存的数据仍在缓存中。但是，您需要先了解程序的数据和数据访问权限，然后才能对信息采取行动。正如手册中所说，
简而言之，Cachegrind 可以告诉您代码中的一些瓶颈在哪里，但它不能告诉您如何解决它们。你必须自己解决这个问题。但至少你有信息！
于 2009-11-12T17:57:29.257 回答