Question

我有一个表现良好的例程。但是，我不得不改变它。这一改变提高了程序的精确度，但却损害了性能。

例程是大量的数学计算，可能是CPU绑定（我仍然需要对此进行更严格的测试，但我99％肯定）。它是用C ++编写的（编译器是Borland C ++ 6）。

我想现在衡量一下例程的表现，首先我考虑测量执行时间，但在我看来这是一种有缺陷的方法，因为可能会有更多的事情发生。

然后我遇到了这个话题：Techniques to measure application performance - Stack Overflow。我喜欢通过MFlops测量的想法。

我的老板建议尝试通过cpu时钟周期进行某种测量，因此测试将与机器无关，但是，我认为这种方法属于MFlops测试。

在我看来，衡量两件事（执行时间和MFlops）是要走的路，但我想听听stackoverflow专家你们的想法。

测量一个称为CPU绑定的例程的性能的方法是什么？

Answer 1

如果你的应用程序受内存限制，那么CPU时钟周期并不意味着那么多。在更快的CPU上，您将花费更多的CPU周期等待相同的缓存未命中。（数学应用可能不受I / O限制）。

另一个问题是某个指令序列的时钟周期数仍然会因架构而异（甚至包括Intel Core1 / Core2之间）。因此，作为性能的绝对衡量标准，一个CPU上的时钟周期几乎没有改进。

我认为他们实际上更糟糕了。与时间不同，用户不关心周期。这对于现代多核CPU尤其重要。使用两倍循环次数和3个核心的“低效”算法将在67％的时间内完成。用户可能会喜欢这样。

Answer 2

你的问题暗示软件已经尽可能快，除了精度问题。我发现情况并非如此，而且我认为你真正想要的就是快速实现它。

我建议测量缺少重点。

你真正需要做的是找到语句或指令（不是函数）1）负责挂钟时间的很大一部分，2）你可以找到一个优化方式。

假设软件具有非平凡的大小，很可能它至少有几层函数调用，很可能这些函数调用中的一些（不是函数，函数调用）负责显着的时间分数并且可以进行优化。

This是找到它们的一种非常好的方式，this就是它的一个例子。

Answer 3

我同意你的老板 - 衡量cpu时钟周期。请注意，可能还有其他事情发生，例如大量缓存未命中会降低代码速度。如果可以，请使用VTune或英特尔的免费工具之一来确定瓶颈的性质。

Answer 4

现在CPU时钟周期与机器无关，即使CPU使用相同的指令集也是如此。 x86（或其他）机器代码将以各种不同的方式切片和切块。这意味着任何事情早已过去的日子（当CPU循环意味着什么时，有许多不同的CPU类型在使用中，它仍然是机器相关的。）

更不用说CPU限制不像过去那样清晰，缓存未命中等等。过去，CPU绑定的进程只受I / O等限制，因为内存访问会占用一定的CPU周期。

你要测量的是性能，我采取的是它的运行速度。在这种情况下，您可能最好测量挂钟时间，重复计算足够多次以获得显着结果。您可以创建一个可以运行不同实现的测试工具，这样您就可以获得可比较的结果。

Answer 5

您可以根据CPU硬件计数器来衡量，VTune Intel配置文件非常擅长。它将根据CPU计数器（指令退役，缓存未命中，分支错误预测）向您显示详细信息，它还会将此与您函数中的每个语句相关联，因此您将非常了解占用最多的成本。

这假设您的函数不受内存限制。

由于

Answer 6

衡量执行时间是可行的方法。

在这种情况下，我认为您希望最小化您的测量以减少变量的数量。

接下来，运行某种基线以校准该特定机器是个好主意。使用最后签入的版本或某种类似于您尝试测量的计算类型的密集例程。然后你可以将基准表达为

relative_time = measured_time_for_routine / measured_time_for_baseline