0

我知道的所有 .net 分析器都没有考虑 CPU 缓存的影响。

鉴于从 CPU 缓存中读取字段比从主内存中读取字段快 100 倍，这可能是一个很大的因素。（我只需要在答案中解释这一点）

我见过太多人花很长时间来加速分析器认为很慢的循环，而在现实生活中，cpu 缓存使它们变得更快。

例如，我希望能够查看数据访问是否大量缺少 cpu 缓存，以及获得我可以更信任的基本分析结果。

在过去，我发现通过使我的数据更加紧凑，它会全部放入 CPU 缓存中，或者更改数据访问的其他数据会产生很大的影响。例如

AccessArrarFromStartAndDoSomething()  
AccessArrayFromEndAndDoSomethingElse()

那么更好

AccessArrarFromStartAndDoSomething()  
AccessArrayStartEndAndDoSomethingElse()

如果阵列不适合 CPU 缓存，但很难找到这种类型的改进。

花费更多的 cpu 周期来使数据更小，以便更好地适应 CPU 缓存可以分散很多系统，但大多数分析器会将您指向另一个方向。

4

2 回答 2

0

我可能误解了您的问题，但我认为答案只是将您的分析器切换到高精度、低细节模式。一个例子是使用ANTS Performance Profiler 的新采样模式：

http://www.simple-talk.com/community/blogs/andrewh/archive/2009/11/13/76420.aspx

于 2010-07-30T11:54:48.713 回答
0

我见过太多人花很长时间来加速分析器认为很慢的循环，而在现实生活中，cpu 缓存使它们变得更快。

一些分析器真的很擅长这样的胡说八道。

你的总体目标是什么？您是否希望在更短的挂钟时间内完成计算？

如果不是，请忽略此答案。

如果是这样，您需要知道是什么导致您可以摆脱挂钟时间。

这与时间的准确性无关。这是关于位置的准确性。我建议您真正需要知道的是，哪些代码行都 1) 负责花费合理的一部分时间，以及 2) 可以做得更好或根本不做。这就是你需要知道的，因为如果没有这样的代码行，那么你要优化什么？

找到这样的代码行的一个很好的方法是任何分析器，1）在调用堆栈的挂钟时间（不是 cpu 时间）上采样， 2）告诉你，对于每一行代码（不是函数）出现在调用堆栈上，它出现在堆栈上的百分比。您的优化候选行是具有较大百分比的行之一。（几个非 .net 示例：Zoom和LTProf。）

坦率地说，我使用的分析器是你已经拥有的。我只是在程序运行缓慢时暂停程序并查看堆栈。我不需要很多样品。事实上，如果有一行代码我可以不用，如果它只出现在两个样本上，我知道它是值得修复的，达到这一点所需的样本越少，它就越大。这是一个更彻底的解释。

几乎总是有多个“瓶颈”。所以我找到了一个大的，修复它，然后再做一遍。解决瓶颈对剩余瓶颈的作用是——它使它们变得更大。这种“放大效果*”让您可以继续前进，直到没有更多的速度可以挤出。

于 2010-07-30T13:15:35.923 回答