情景描述
先上代碼:
code1:
void Graph::shufle(int cnt) {
for (int i = 1; i<cnt; i++) {
unsigned int swid = fastrand() % (cnt-i) ;
std::swap(iCons[cnt - i], iCons[swid]);
std::swap(jCons[cnt - i], jCons[swid]);
std::swap(dCons[cnt - i], dCons[swid]);
std::swap(wCons[cnt - i], wCons[swid]);
}
}
code2
// 作用為快速取得隨機數
unsigned int g_seed = 0;
unsigned int fastrand() {
g_seed = (214013 * g_seed + 2531011);
return g_seed;
}
code3
// 與代碼2的區別在於取值范圍變為了65535
unsigned int fastrand() {
g_seed = (214013 * g_seed + 2531011);
return (g_seed >>16) & &7FFF;
}
實際效果:
cnt : 107403264
code2 timeuse : 3489 ms
code3 timeuse : 984 ms
分析
兩種代碼實現結果相差接近3.5倍,起初懷疑是取模造成的。懷疑在-O3的編譯器優化下,較小的值取模往往可以直接返回該值本身。將code1
中swap去掉后發現,就算是code2
方法,光產生隨機數只需要69ms
。因此排除取模為性能瓶頸。
我們可以注意到,code3
產生的數往往是小於65535
的,而i
是依次遞減的。因此,對於code3
而言,訪問的內存總是在前65535
個地址中,以及依次移動的cnt-i
。而code2
產生的隨機數對cnt-i
取模后,該數取值范圍很大很大,因此總是造成cache miss
,因此比code2
慢3.5倍。