逻辑时间与在Ubuntu Linux操作系统

物理时候我测量这样的两个事件之间的物理时间：逻辑时间与在Ubuntu Linux操作系统

#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？

来源

2010-10-25 lurscher

确定后有点研究的我发现的getrusage同时填写需要提到：

getrusage man page

所以基本上需要的代码非常相似，我如何测量物理时间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）C消耗urrent处理时间

2），分辨率可达微秒

我调查升压Date.Time，但文件中没有什么提的进程或用户对系统的时候，我认为图书馆只是关心测量物理时间

来源

2010-10-26 12:33:14 lurscher

似乎这种解决方案也不完整;显然，从一段时间以来，rusage的结果不会有新的价值（我的猜测是，直到下一次上下文交换重新输入时才会获得新的值）。如果这个假设是有效的，那就意味着每次逻辑时间改变时都必须实施一个hackaround，存储物理时间，那么只要报告的逻辑时间没有改变，就必须添加自上次改变以来的物理时间增量。并且这可能既不是完全准确的，因为我不知道在上次上下文交换之前有多远。把时间带到linux邮件列表 – lurscher 2010-10-26 18:31:59

我也尝试过'clock_gettime'，结果是'getrusage'的结果和'gettimeofday'的结果之间的中间值，并且由于我们最终是在一个可靠的基准测量之后，我不相信任何选择都比另一个更好... http://www.guyrutenberg.com/2007/09/22/profiling-code-using-clock_gettime/ – lurscher 2010-10-30 21:37:27

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

至于'总时间>物理运行时间'，我确实在多线程计时中看到了。这只是一个'会计'thingie：如果所有线程都有效，所有cpu'消耗'都会被添加，并且在多线程代码中可能会超过已用时间，并会增加一些调度开销并使您拥有超过时间。

来源

2010-10-25 15:11:13

有趣的是，然而我使用的测试程序是单线程的......或者我认为。我目前只与unittest-cpp连接，所以也许库创建一个线程 – lurscher 2010-10-25 16:02:16

使用getrusage我现在得到的处理时间一直低于物理时间 - 时钟结果绝对看起来很奇怪 – lurscher 2010-10-26 13:02:04

是的，任务操作系统一些其他的事情正在发生，需要考虑。这难道不是“你的”时间和总时间之间的差异的一部分吗？ – 2010-10-26 13:49:47

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

来源

2010-10-25 16:09:31

对！纯粹的机会，本地我的CLOCKS_PER_SEC其等于10e6所以结果似乎很好 – lurscher 2010-10-25 16:18:16

逻辑时间与在Ubuntu Linux操作系统

回答

相关问题