1

我正在测量两个事件之间的物理时间，如下所示：

#include <time.h>
#include <sys/time.h>

timeval wall_time0;
timeval wall_time1;

// start of period measurement
gettimeofday( &wall_time0 , 0);

...stuff happening 

// end of period measurement
gettimeofday( &wall_time1 , 0);

return ( ( wall_time1.tv_sec - wall_time0.tv_sec ) + (( wall_time1.tv_usec - wall_time0.tv_usec )/(double)1000000) );

但是现在，我需要一种方法来测量线程实际使用的逻辑时间。也就是说，理论上应该是物理时间，减去运行其他线程和/或系统和内核逻辑所花费的时间。

我认为这是这样做的方法：

clock_t mTime0;
clock_t mTime1;

//start of period measurement
mTime0=clock();

... stuff happening


//end of period measurement
mTime1=clock();
return (mTime1-mTime0)/(double)CLOCKS_PER_SEC;

但是做了一些测量，我发现了两个问题：

1）对于某些测量，它大于物理时间，这是不对的（即：对于某些循环，物理时间将为 0.2495 .. 并且“逻辑”（使用 clock() 测量）将为 0.27，对于较小的测量它会只是四舍五入到零，这导致了第二个问题......）

2) 结果时间似乎比 gettimeofday 返回的时间粗多了

有没有更好的方法来测量 linux 中的本地线程时间？

4

3 回答 3

3

您可以使用一些更高精度的选项 - 查看sys/timex.h. 例如，Boost Date.Time 也有毫秒和更高精度的计时器。

至于“总时间>物理经过时间”，我确实在多线程计时中看到了这一点。这只是一个“会计”的事情：添加了所有的 cpu“消耗”，如果所有线程都工作，那么在多线程代码中很可能超过经过的时间，增加了一些调度开销，并且你有超过经过的时间。

于 2010-10-25T15:11:13.763 回答
2

的tv_usec字段struct timeval以微秒为单位，而不是以 为单位1/(double)CLOCKS_PER_SEC。

于 2010-10-25T16:09:31.553 回答
0

好的，经过一番研究，我发现 getrusage 满足了上述两个需求：

getrusage 手册页

所以基本上所需的代码与我测量物理时间的方式非常相似gettimeofday，只是现在我使用getrusage

#include <time.h>
#include <sys/time.h>
#include <sys/resource.h>

timeval processed_time0;
timeval processed_time1;
rusage paramStruct
// start of period measurement
int result = getrusage( &paramStruct);
processed_time0 = paramStruct.ru_utime;

...stuff happening 

// end of period measurement
int result = getrusage( &paramStruct );
processed_time1 = paramStruct.ru_utime;

return ( ( processed_time1.tv_sec - processed_time0.tv_sec ) + (( processed_time1.tv_usec - processed_time0.tv_usec )/(double)1000000) );

这种方式给了我两个

1）当前进程消耗时间

2) 微秒分辨率

我调查了 Boost Date.Time，但在文档中没有提到进程或用户与系统时间，我认为该库只关心测量物理时间

于 2010-10-26T12:33:14.713 回答