//說明：原文和作者不祥。
pc硬體中，有三種基本的獲得時間的方法。
1）the 「tick」 counter。這是個毫秒（千分之一妙）的記時器，可以用temegettime()或者gettickcount()獲得。這個記時器是有isa中斷控制器控制的（可能現在被虛擬化為主板上的晶元，而不是原來放在cpu中）。這是一種精度為毫秒的方法。讀取它需要乙個bus從lpc到isa介面轉換的請求，所以，這種方法有一點慢（大概1－2微秒）。如果當時的bus正處於繁忙中，比如遊戲正在使用agp和dma處理圖形和聲音，這種方法可能會經常丟失一段時間，導致延遲。
2）the 「performance」 counter。這是一種微秒（百萬分之一秒）記時器，可以通過呼叫queryperformancecounter()來讀取。這個記時器，每秒觸發一百萬次多一點，或者是三百萬次多一點，取決於bus。它可能是由pci控制器觸發的。讀取它，至少要經過cpu－北橋bus轉移，但這樣並不是很爽快！可能要花一毫妙。
3）the 「time stamp」 counter.這是cpu內部的乙個暫存器，用的是乙個64位的記時器，記錄的是cpu從開機以來執行的時間，可以記錄130年！讀取這個值非常的快，它就在cpu內部（讀取一次需要40個週期）。這種方法在精確獲得一段**的執行時間時非常有用。
不幸的是，這三種方法，當你想要把他們轉換位實際時間，還需要獲得cpu時間和秒之間的關係。這在cpu開機運作的時候，就被決定了，使用的其他的記時器。這種方式可能有一些不精確。更糟的是，在筆記本中，這個暫存器的更新頻率會在乙個較大的範圍內波動，因為，此時cpu的速度也在變化。
所以，在精確計算pc的實際時間的時候，沒有「銀彈」。如果你想要模擬網路上的同步，你就可能不得不將這三種方法結合起來。我在一般情況下使用cycle sounter，因為這樣快而且損失小，然後，我通過後兩種記時器不斷校正這個時間。如果他們的結果不一致，我就丟掉那個取樣點，等到遲一些時候再說。這看起來執行得十分不錯。
在cpu的速度可以變化的機器上，你可能會很惱火。你可以做的是選擇時鐘類的另乙個例項，並且希望這種跳躍式的時間帶來的不精確不會完全破壞掉你到應用程式。
PC的時間精確嗎？
origin rdtsc 讀取不準確這個應該算是cpu的bug，由tsc的計數方式，多核等影響。多核tsc的問題目前ms和amd 通過軟體補丁的方式來解決了。而speedstep以及cpu頻率變化的影響intel已經對tsc進行修正了。rdtsc 畢竟是比較快速的讀取方法，使用acpi pm tim...
時間管理 我的android，我的PC
我們是不是不停的抱怨每天的時間不夠用，但是問起自己來，到底時間花在哪了？又回答不上來。然後自己又在拼命的想自己的時間到底花在了什麼地方，做了什麼事情。我們是不是有時候在不停的幹同一件事情，然後有時候幹完了事情之後，發現自己一無所獲。時間沒了，收穫呢？也沒了。咋辦咧？所以合理安排時間成了我們高效學習的...
典型 PC 系統各種操作指令的大概時間
典型 pc 系統各種操作指令的大概時間 execute typical instruction 執行基本指令 1 1,000,000,000 sec 1 nanosec fetch from l1 cache memory 從一級快取中讀取資料 0.5 nanosec branch mispredi...