邏輯時間與在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操作系統

回答

相關問題