2

现在我正在加载一个文件,然后使用 gettimeofday 并使用 tv_usec 跟踪 CPU 时间

我的结果各不相同,我得到 250 到 280,但有时是 300 或 500。我写了 usleep and sleep (0) 和 (1) 都没有成功。时间仍然相差很大。我认为 sleep(1) (linux 中的秒数,而不是 ms 中的 windows 睡眠)会解决它。如何以更一致的方式跟踪时间以进行测试?也许我应该等到我有更大的测试数据和更复杂的代码后再开始测量?

4

3 回答 3

4

目前在 Linux(以及一般的 POSIX)上推荐的 high-rez 时间接口是 clock_gettime。请参阅手册页。


clock_gettime(CLOCK_REALTIME, struct timespec *tp) //  for wall-clock time
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, struct timespec *tp) //  for CPU time

但请阅读手册页。请注意,您需要链接 -lrt,因为 POSIX 是这样说的,我猜。对于定义自己的clock_gettime的旧程序,也许是为了避免-lc中的符号冲突?但是动态库使用弱符号......

最好的睡眠功能是 nanosleep。它不会乱用信号或任何诸如睡眠之类的废话。它被定义为只是睡觉,没有任何其他副作用。它会告诉您是否早起(例如从信号中),因此您不必调用另一个时间函数。

无论如何,您将很难测试一个涉及系统调用的简短内容的代表。变化的机会很大。例如,调度程序可能会决定需要执行其他一些工作(如果您的流程刚刚开始,则不太可能;您还没有用完您的时间片)。CPU 缓存(L2 和 TLB)很容易实现。

如果您有一台多核机器和一个针对您正在优化的代码的单线程基准测试,您可以将其实时优先级固定到您的一个内核。确保您选择不处理中断的内核,否则您的键盘(和其他所有东西)将被锁定,直到它完成。使用taskset(用于固定到一个CPU)和chrt(用于设置实时优先级)。请参阅我用这个技巧发送给 gmp-devel 的这封邮件:http: //gmplib.org/list-archives/gmp-devel/2008-March/000789.html

Oh yeah, for the most precise timing, you can use rdtsc yourself (on x86/amd64). If you don't have any other syscalls in what you're benching, it's not a bad idea. Grab a benchmarking framework to put your function into. GMP has a pretty decent one. It's maybe not set up well for benchmarking functions that aren't in GMP and called mpn_whatever, though. I don't remember, and it's worth a look.

于 2009-12-05T06:43:51.923 回答
2

您是否尝试测量加载文件需要多长时间?通常,如果您正在对已经非常快(亚秒级)的一些代码进行性能测试,那么您将需要多次重复相同的代码(例如一千或一百万),对整个时间进行计时,然后将总时间除以迭代次数。

话虽如此,我不太确定您使用 sleep() 是为了什么。你能发布一个你打算做什么的例子吗?

于 2009-12-05T05:48:49.430 回答
1

我建议将该代码放在 for 循环中。运行它超过 1000 或 10000 次迭代。如果您只执行一些说明,这会出现问题,但它应该会有所帮助。

当然,更大的数据集也有帮助。

sleep 将从 cpu 取消调度您的线程。它不能精确地计算时间。

于 2009-12-05T05:49:09.713 回答