---

如我前面說的, 這個問題要看 CPU 和作業系統而定...
CPU 的 rdtsc (rdtscp) 指令讀出來的 counter 直接影響計時精確度,
Windows 作業系統和 UNIX 家族各自有各自的 function call ...

需要使用到精確時鐘的操作大致有以下幾種:
 1. 時鐘, 看目前時間, 或計算兩次看錶之間經過多久
 2. 等待, delay 一段時間不做事
 3. 鬧鐘, 某個時間要醒來做某事

○UNIX:
最準的當然是 POSIX.1-2001 規定的 clock_* 和 timer_* 系列:
clock_gettime(): 取得目前時間
clock_getres(): 取得精確度
clock_nanosleep() 或 nanosleep(): delay, 保證睡過頭
timer_create(), timer_settime() 系列: 鬧鐘

select(): 可以代替 sleep(), 在古代沒有 nanosleep() 而 usleep() 又很兩光地
        busy waiting 時, select() 曾經是精準 sleep 的最佳解。
usleep(): 已過氣, 建議改用 nanosleep()
ualarm(): 可以用 us 為單位指定時間發 SIGALRM
gettimeofday(): 取得目前時間
以上計時單位是 us, 而且你無法取得精確度... 但可以慶幸的是 Linux 本來精確度
就是看 CPU, 所以普通的 PC 精確度 < 1 us 是基本的...

clock(): 老掉牙 function, 單位是 clock, 用 CLOCKS_PER_SEC 可以換算成秒,
        我的 Linux 上 CLOCKS_PER_SEC 是 1000000 也就是說 clock = us
        但印象中以前看過 #define CLOCKS_PER_SEC 1000 的舊開發環境...

time(): 最常見的時間函式, 回傳單位是秒...
        我每次看見有人寫 srand(time(NULL)); 就會抓狂...
        現在科學昌明的 21 世紀有 /dev/urandom 這個東西耶...

最準的是 High-Resolution Timer 系列, 其精確度和 CPU 的 rdtsc 一樣準:
QueryPerformanceCounter(): 取得 rdtsc 的 counter 值
QueryPerformanceFrequency(): 取得一秒有幾個 counter, Sandy bridge 以後的
        CPU, 其 frequency 值等於 CPU 時脈 (2.66 GHz CPU, freq = 2672760000)
這個 counter 精確度 < 1 ns
但很遺憾地, Windows 沒有對應的 ns 級 sleep 和 alarm function,
甚至連 us 級都從缺...

不夠準的:
Multimedia Timer: 以前曾經是最準的 timer, 但這個準確度是有代價的,
        當你用 timeBeginPerios(1) 設定精確度為 1 ms 的時候,
        原本 18.2Hz 的 timer chip 會被加速, 導致 timer interrupt 數量暴增,
        然後整個系統效能反而變得很悲劇...
GetTickCount(): 單位是 ms, 但實際精確度無法得知, 通常就是同上...
        另外它每 49.7 天會 overflow 一次, 這曾經造成 Win98 著名的 49.7 天
        當機 bug 以及 Debug 模式的 GetTickCount overflow condition test
GetTickCount64(): 這下再也不會 overflow 了... (鬆一口氣)
clock(): 作用和 Linux 的 clock() 一樣, 只不過 CLOCKS_PER_SEC 是 1000
GetSystemTime(), GetSystemTimeAsFileTime(): 最小單位是 ms
        很兩光的是你沒辦法直接取得 64-bit LARGE_INTEGER 的時間值...
Sleep() 和 SleepEx(): 單位是 ms, 但實際精確度同 Multimedia Timer
SetTimer(): 最常見的鬧鐘, 最小值 10 ms 起跳。

順帶一提 rdtsc 指令並不是絕對神準, 有幾個狀況會出槌,
但這裡並不是組合語言板, 為了避免被水桶還是就此打住。

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.137.5.19

感謝指正, 古代許多 UNIX 的 libc 確實是用 busy waiting 在實作, 我記得在
W. Richard Stevens 的 UNIX Network Programming 有提到。由於 usleep 是個
library function, 不是 system call, 所以要看各家 C library 不同實作方式。

剛剛看了 GNU libc 2.18 的 source code, 在有 nanosleep() system call 的
Linux 上是用 nanosleep 實作, 在沒有 nanosleep() 的古代 BSD 上是用 select()
實作, 所以使用 glibc2 的系統應該是不會有 busy waiting 問題。

Linux 的 nanosleep() 是 kernel 裡的 system call, 以前曾經發生過在某個 mode
之下為了種種原因還是用 busy waiting 來實作, 不過 2.6 和 3.x 之後的 kernel
已經修正, 不用再擔心了。


DVFS (CPU 變頻) 這功能被罵翻了 XD
※ 編輯: Schottky        來自: 220.137.37.104       (09/25 13:03)

--