申明：Blog上的文章只是個(gè)人學(xué)習(xí)的一些記錄和總結(jié)，這些記錄部分來自于網(wǎng)絡(luò)，加上自己的一些理解，有些已經(jīng)找不到最原始的出處了，在此對(duì)大牛們的貢獻(xiàn)表示感謝，如有侵權(quán)的地方，請(qǐng)通知我，我會(huì)盡快刪除。
對(duì)關(guān)注性能的程序開發(fā)人員而言，一個(gè)好的計(jì)時(shí)部件既是益友，也是良師。計(jì)時(shí)器既可以作為程序組件幫助程序員精確的控制程序進(jìn)程，又是一件有力的調(diào)試武器，在有經(jīng)驗(yàn)的程序員手里可以盡快的確定程序的性能瓶頸，或者對(duì)不同的算法作出有說服力的性能比較。GPU程序性能瓶頸測(cè)試，比較常用的工具是NVIDIA PerfHUD ，它能準(zhǔn)確測(cè)量出渲染管線的每個(gè)階段消耗的時(shí)間，從時(shí)間軸上可以很明顯的看出在渲染一幀是，渲染瓶頸在哪個(gè)階段，從而根據(jù)具體情況進(jìn)行優(yōu)化。CPU程序性能分析工具，Intel公司的 VTune在業(yè)界比較常用，一直想用，還沒試過。
然而下面將要介紹的，從網(wǎng)上搜集到的一些關(guān)于程序代碼段時(shí)間統(tǒng)計(jì)函數(shù)，用于單個(gè)算法的性能分析，比上面提及的工具，更加方便，輕量，易用，根據(jù)你對(duì)時(shí)間統(tǒng)計(jì)的精度要求，選擇不同的時(shí)間統(tǒng)計(jì)函數(shù)。
1.C語言時(shí)間庫<time.h>的clock()函數(shù)
unsigned long sTime,eTime;
double dTime;
sTime = click();
/**////TODOeTime = click();
dTime = (double)(eTime-sTime)/CLOCKS_PER_SEC;
2. RDTSC :(Read Time Stamp Counter)
[1]在Intel Pentium以上級(jí)別的CPU中，有一個(gè)稱為“時(shí)間戳（Time Stamp）”的部件，它以64位無符號(hào)整型數(shù)的格式，記錄了自CPU上電以來所經(jīng)過的時(shí)鐘周期數(shù)。由于目前的CPU主頻都非常高(1GHz = 10
9)，因此這個(gè)部件可以達(dá)到納秒級(jí)(
一秒的10億分之一，即等于10的負(fù)9次方秒)的計(jì)時(shí)精度。這個(gè)精確性是上述方法所無法比擬的。在Pentium以上的CPU中，提供了一條機(jī)器指令RDTSC（Read Time Stamp Counter）來讀取這個(gè)時(shí)間戳的數(shù)字，并將其保存在EDX:EAX寄存器對(duì)中。由于EDX:EAX寄存器對(duì)恰好是Win32平臺(tái)下C++語言保存函數(shù)返回值的寄存器，所以我們可以把這條指令，嵌入?yún)R編代碼的方式，看成是一個(gè)普通的函數(shù)調(diào)用。像這樣：
inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}
但是不行，因?yàn)镽DTSC不被C++的內(nèi)嵌匯編器直接支持，所以我們要用_emit偽指令直接嵌入該指令的機(jī)器碼形式0X0F、0X31，如下：
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
以后在需要計(jì)數(shù)器的場(chǎng)合，可以調(diào)用兩次GetCycleCount函數(shù)，比較兩個(gè)返回值的差，像這樣：
#include <iostream>
#include <Windows.h>
using namespace std;
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
int main()
{
unsigned long t;
t = (unsigned long)GetCycleCount();
Sleep(1000);
t = (unsigned long)GetCycleCount() - t;
cout<<"時(shí)間："<<t<<endl;
system("pause");
return 0;
}
我的CPU是2.0GHz
所以輸出結(jié)果：
時(shí)間：1995027270
程序所花時(shí)間秒數(shù) = RDTSC讀出的周期數(shù)T1-RDTSC讀出周期數(shù)T2 / CPU主頻速率（Hz）
缺點(diǎn)：
1.數(shù)據(jù)抖動(dòng)比較厲害，每次測(cè)得結(jié)果都不一樣，波動(dòng)幅度上百甚至上千
2.在多核下不準(zhǔn)確或不可用，有以下幾個(gè)方面的原因
[2]：
a.兩個(gè)CPU核的內(nèi)部計(jì)數(shù)器不同步。如果程序兩次讀取這個(gè)計(jì)數(shù)器的時(shí)候恰好被輪換到不同的核上，那么用來計(jì)時(shí)就會(huì)有比較大的誤差。
b.CPU 的時(shí)鐘頻率可能變化，例如筆記本電腦的節(jié)能功能；
c.亂序執(zhí)行導(dǎo)致 RDTSC 測(cè)得的周期數(shù)不準(zhǔn)，這個(gè)問題從 Pentium Pro 時(shí)代就存在。
解決方法
[3]：可以采用設(shè)定線程親核性的方法。函數(shù)SetThreadAffinityMask可以指定某線程只在某些核上運(yùn)行（由第二個(gè)參數(shù)設(shè)定，每個(gè)位代表一個(gè)核）。例如，在需要調(diào)用RDTSC的那個(gè)線程里執(zhí)行SetThreadAffinityMask(GetCurrentThread(), 0x00000001);就能保證該線程只在第一個(gè)核上運(yùn)行，不會(huì)因?yàn)閮蓚€(gè)核的RDTSC計(jì)數(shù)器不同步而造成計(jì)時(shí)誤差。我在windows7和VS2005下測(cè)試，測(cè)出的數(shù)據(jù)和我CPU主頻不符，我一度懷疑剛買的筆記本是不是被刷屏了，后來還找了其他的一些測(cè)CPU的工具，比如CPU-Z，這個(gè)問題還沒解決。
3.使用QueryPerformanceCounter查詢函數(shù)方法
這個(gè)方法在多核下照常有效，QueryPerformanceFrequency()參數(shù)只和主板上的高精度定時(shí)器的晶振頻率相關(guān)
在面的例子是兩種求平方根的算法的性能比較，一種采用庫函數(shù)的sqrt(),另一種方法是《編程珠璣》上介紹的牛頓迭代法求平方根，原理類似于二分查找，但是牛頓迭代法收斂速度相比快很多。
#include <iostream>
#include <cmath>
using namespace std;
int main()
{
//a待輸入的開平方根數(shù)
//x 選取的x0點(diǎn)
//y 每次迭代的中間值
double a, x,y;
unsigned long start,endt;
cin>>a;
LARGE_INTEGER t1,t2,tc;
QueryPerformanceFrequency(&tc);
printf("Frequency:%u\n",tc.QuadPart);
QueryPerformanceCounter(&t1);
if (a<0)
cout<<"負(fù)數(shù)沒有平方根！"<<endl;
else
{
x = 1;
y = (x+a/x)/2;
while (x!=y)
{
x = y;
y = (x+a/x)/2;
}
}
QueryPerformanceCounter(&t2);
//牛頓迭代法求平方根所需時(shí)間;
printf("Lasting Time:%u\n",(t2.QuadPart-t1.QuadPart));
//duration = (double)(finish - start)/CLOCKS_PER_SEC ;
cout <<a<<"的平方根為："<<x<<endl;
QueryPerformanceCounter(&t1);
sqrt(a);
QueryPerformanceCounter(&t2);
//math.h庫函數(shù)sqrt求平方根所需時(shí)間;
printf("Lasting Time:%u\n",(t2.QuadPart-t1.QuadPart));
cout<<a<<"的平方根為："<<sqrt(a)<<endl;
system("pause");
return 0;
兩種求平方根所需時(shí)間對(duì)比如下：
在圖形學(xué)中求平方根使用頻率非常高，尤其是在碰觸檢測(cè)中，盡量提高求平方根的效率是非常有必要的。
總結(jié)：效率就是生命，在平時(shí)的項(xiàng)目開發(fā)中盡量做到簡(jiǎn)單，簡(jiǎn)單代表高效。這是檢測(cè)高效的第一步。
引用：
[1]:http://zhidao.baidu.com/question/41853032.html
[2]:http://blog.csdn.net/Solstice/archive/2010/01/16/5196544.aspx
[3]:http://blog.21ic.com/user1/5184/archives/2009/65439.html