在Win32中，有沒有辦法獲得一個獨特的CPU週期數或類似的東西，這對於多個進程/語言/系統等是一致的。如何在Win32中獲取CPU週期數？
我正在創建一些日誌文件，但必須生成多個日誌文件，因爲我們正在託管.NET運行時，並且我想避免從一個到另一個進行日誌記錄調用。因此，我認爲我只是製作兩個文件，合併它們，然後對它們進行排序，以獲得涉及跨世界調用的連貫時間線。
但是，每次調用GetTickCount都不會增加，所以這不可靠。是否有更好的號碼，以便在排序時按照正確的順序接聽電話？
編輯：由於@Greg是把我的軌道QueryPerformanceCounter的，該做的把戲。
您可以使用RDTSC CPU指令（假設爲x86）。該指令給出了CPU週期計數器，但請注意它會非常快速地增加到其最大值，然後重置爲0.如維基百科文章中提到的那樣，使用QueryPerformanceCounter函數可能會更好。
Heres an interesting article!說不使用RDTSC，而是使用QueryPerformanceCounter。
結論：
使用普通的舊
timeGetTime()做 時間不是很多 基於Windows的操作系統 可靠的，因爲該系統 計時器的粒度可高達10-15 毫秒，這意味着timeGetTime()僅準確到 10-15毫秒。 [請注意， 高粒度出現在基於NT的 操作系統（如Windows NT， 2000和XP）上。 Windows 95和98傾向於 有更好的粒度， 周圍1-5毫秒。]但是，如果調用
timeBeginPeriod(1)在 程序的開始（和timeEndPeriod(1)在 年底），timeGetTime()通常會 精確到1-2毫秒， ，並會爲您提供極其準確的時間信息 。
Sleep()表現相似;時間的長短 是Sleep()實際上是睡 齊頭並進在手與 粒度timeGetTime()，所以 調用timeBeginPeriod(1)一次後，Sleep(1)實際上會睡1-2 毫秒，Sleep(2)2-3，和因此 開啓（而不是以高達10-15毫秒的增量 休眠）。對於更高的精確定時 （亞毫秒級精度），你會 可能要避免使用 組裝記憶RDTSC，因爲它是 很難校準;相反，使用
QueryPerformanceFrequency和QueryPerformanceCounter，這是 精確到小於10微秒 （0.00001秒）。對於簡單的計時，都timeGetTime 和QueryPerformanceCounter的做工精良， 和QueryPerformanceCounter的是 顯然更爲準確。但是，如果 你需要做的任何一種「定時 暫停」（如必要 幀率限制）的，你需要 小心坐在一個循環中調用 QueryPerformanceCounter的，等待 它達到一定的值;這將使 吃掉100％的處理器。 相反，考慮混合方案， 在那裏你調用sleep（1）（不要忘記 timeBeginPeriod（1）第一！），只要 你需要傳遞的 時間超過1毫秒，然後只進入 QueryPerformanceCounter的100％ - 忙碌的迴路 完成最後的< 1/1000的 秒延遲您需要。這 會給你超精確的延遲 （精確到10微秒），與 非常小的CPU使用率。請參閱上面的代碼 。
使用GetTickCount並在合併日誌文件時添加另一個計數器。不會給你在不同日誌文件之間的完美序列，但它至少會保持每個文件的所有日誌按正確的順序排列。
滴答計數似乎增加與毫秒輸出重合，這就是爲什麼我需要更準確一些的原因。 – 2008-09-26 12:00:30
System.Diagnostics.Stopwatch.GetTimestamp（）返回自時間原點以來的CPU週期數（可能在計算機啓動時，但我不確定），我從來沒有看到它在兩次調用之間沒有增加。
CPU週期將針對每臺計算機特定，因此您無法使用它來合併2臺計算機之間的日誌文件。
謝謝，我只會在同一時間段內合併在同一臺計算機上生成的文件，這樣才能工作。現在我只需要找出該方法實際調用的內容:) – 2008-09-26 11:59:37
RDTSC輸出可能取決於當前內核的時鐘頻率，對於現代CPU而言，這種時鐘頻率既不恆定，也不依賴於多核機器。
使用系統時間，並且如果處理來自多個系統的訂閱源使用NTP時間源。您可以通過這種方式獲得可靠，一致的時間讀數;如果開銷太大以至於無法達到您的目的，則使用HPET計算自上次已知的可靠時間讀數以來的時間比單獨使用HPET的時間更長。
請避免timeBeginPeriod（）;它會影響整個系統的調度程序，並可能導致節能問題。 – MSalters 2008-09-26 13:03:04