C 中 clock() 函数的准确性

Accuracy of clock() function in C

我有一些代码试图确定代码块的执行时间。

#include <time.h>
#include <stdio.h>

int main()
{
   clock_t start_t, end_t, total_t;
   int i;

   start_t = clock(); //clock start
   printf("Starting of the program, start_t = %ld\n", start_t);

   printf("Going to scan a big loop, start_t = %ld\n", start_t);
   for(i=0; i< 10000000; i++)  //trying to determine execution time of this block
   {
   }
   end_t = clock(); //clock stopped
   printf("End of the big loop, end_t = %ld\n", end_t);

   total_t = (long int)(end_t - start_t);
   printf("Total time taken by CPU: %lu\n", total_t  );

   return(0);
}

代码片段在我机器上的输出是

Starting of the program, start_t = 8965
Going to scan a big loop, start_t = 8965
End of the big loop, end_t = 27259
Total time taken by CPU: 18294

因此,如果我的 CPU 在 21 MHz 时 运行 并假设这是唯一执行的事情,则每个机器周期将大约等于 47 纳秒,因此 (18294 * 47) = 859818 纳秒。

这是我代码中 for 循环的执行时间吗?我是不是在做一些不正确的假设。

clock函数使用的时间单位是任意的。在大多数平台上,它与处理器速度无关。它通常与外部定时器中断的频率有关——可以在软件中配置——或者与经过多年处理器发展以保持兼容性的历史值有关。您需要使用宏 CLOCKS_PER_SEC 转换为实时。

printf("Total time taken by CPU: %fs\n", (double)total_t / CLOCKS_PER_SEC);

C 标准库旨在可在广泛的硬件上实现,包括没有内部计时器并依赖外部外围设备来报时的处理器。许多平台有比 time 更精确的挂钟时间测量方法,比 clock 更精确的测量 CPU 消耗的方法。例如,在 POSIX 系统(例如 Linux 和其他类 Unix 系统)上,您可以使用具有微秒级精度的 getrusage

struct timeval start, end;
struct rusage usage;
getrusage(RUSAGE_SELF, &usage);
start = usage.ru_utime;
…
getrusage(RUSAGE_SELF, &usage);
end = usage.ru_utime;
printf("Total time taken by CPU: %fs\n", (double)(end.tv_sec - start.tv_sec) + (end.tv_usec - start.tv_usec) / 1e-6);

如果可用,clock_gettime(CLOCK_THREAD_CPUTIME_ID)clock_gettime(CLOCK_PROCESS_CPUTIME_ID) 可能会提供更好的精度。它具有纳秒精度。

请注意精度和准确度之间的区别:精度是报告值的单位。准确性是报告值与实际值的接近程度。除非您在 real-time system 上工作,否则无法保证一段代码需要多长时间,包括调用测量函数本身。

一些处理器有 cycle 时钟来计算处理器周期而不是挂钟时间,但这非常系统特定。

无论何时进行基准测试,请注意您要测量的是在这些特定情况下该特定 CPU 上该特定可执行文件的执行情况,结果可能会也可能不会推广到其他情况。例如,除非您关闭优化,否则大多数编译器都会优化您问题中的空循环。测量未优化代码的速度通常毫无意义。即使您在循环中添加了实际工作,也要当心玩具基准测试:它们通常不具有与真实世界代码相同的性能特征。在 PC 和智能手机等现代高端 CPU 上,CPU 密集型代码的基准测试通常对缓存效果非常敏感,结果可能取决于其他 运行在系统上,在确切的 CPU 模型上(由于不同的缓存大小和布局),在恰好加载代码的地址上,等等