我正在编写一个必须对大型数组进行排序的程序(最多400万个文本字符串)。好像我做得很好,因为radixsort和mergesort的组合已经将原来的q(uick)排序执行时间缩短了不到一半。
执行时间是主要的一点,因为这是我用来基准我的代码。
我的问题是:
是否有更好的(即更可靠的)基准测试程序的方式而不仅仅是执行的时间?它有点工作,但是如果运行两次,相同的程序(运行相同的后台进程)通常会有稍微不同的执行时间。
这有点挫败了检测小改进的目的。而一些小的改进可能会增加一个大的......
提前感谢任何输入!
结果:
我设法让gprof在Windows下工作(使用gcc和MinGW)。与我的普通编译器(tcc)相比,gcc表现不佳(考虑执行时间),但它给了我很多洞察力。
答案 0 :(得分:11)
尝试使用分析工具,该工具还会显示程序花费时间的位置。 gprof
是经典的C分析工具,至少在Unix上。
答案 1 :(得分:3)
查看time命令。它跟踪进程使用的CPU时间和挂钟时间。您还可以使用类似gprof的内容来分析代码,以查找实际花费最多时间的程序部分。您可以在代码中使用计时器进行低技术版本的分析。 Boost有一个很好的timer类,但很容易推出自己的类。
答案 2 :(得分:2)
我认为只测量一段代码执行所需的时间就足够了。您的环境是一个不断变化的环境,因此您必须采用统计方法来衡量执行时间。
基本上,您需要进行N
测量,丢弃异常值,并计算平均值,中位数和标准差运行时间,并进行不确定度测量。
这是一篇很好的博客,解释了为什么以及如何执行此操作(使用代码):http://blogs.perl.org/users/steffen_mueller/2010/09/your-benchmarks-suck.html
答案 3 :(得分:1)
到目前为止,您对计时执行时间有何用处?对于初学者来说,clock()
中有C89 time.h
。在unixoid系统上,您可能会发现getitimer()
ITIMER_VIRTUAL
来测量进程CPU时间。有关详细信息,请参见相应的手册页。
您还可以使用POSIX shell的times
实用程序来对进程及其子进程使用的处理器时间进行基准测试。分辨率取决于系统,就像分析一样。尝试将C代码包装在一个循环中,根据需要多次执行它以减少基准测试报告时的“抖动”。
答案 4 :(得分:1)
从测试工具中调用您的例程,执行N + 1次。忽略第一次迭代的时间,然后取迭代的平均值1..N。忽略第一次的原因是由于各种影响,例如通常会略微膨胀。虚拟内存,被分页的代码等。平均N次迭代的原因是你摆脱了由其他进程,调度程序等引起的假象。
如果您在Linux或类似设备上运行您可能还想使用taskset
将代码固定到特定的CPU内核(假设它是单线程的),理想情况下不是核心0,因为这往往会处理所有中断。