1. 程式人生 > >為什麼處理排序的陣列要比非排序的快

為什麼處理排序的陣列要比非排序的快

這世上有三樣東西是別人搶不走的:一是吃進胃裡的食物,二是藏在心中的夢想,三是讀進大腦的書

為什麼處理排序的陣列要比非排序的快

問題

以下是c++的一段非常神奇的程式碼。由於一些奇怪原因,對資料排序後奇蹟般的讓這段程式碼快了近6倍!!

#include <algorithm>
#include <ctime>
#include <iostream>

int main()
{
    // Generate data
    const unsigned arraySize = 32768;
    int data[arraySize];

    for (unsigned c = 0; c < arraySize; ++c)
        data[c] = std::rand() % 256;

    // !!! With this, the next loop runs faster
    std::sort(data, data + arraySize);

    // Test
    clock_t start = clock();
    long long sum = 0;

    for (unsigned i = 0; i < 100000; ++i)
    {
        // Primary loop
        for (unsigned c = 0; c < arraySize; ++c)
        {
            if (data[c] >= 128)
                sum += data[c];
        }
    }

    double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;

    std::cout << elapsedTime << std::endl;
    std::cout << "sum = " << sum << std::endl;
}
  • 沒有std::sort(data, data + arraySize);,這段程式碼運行了11.54秒.
  • 有這個排序的程式碼,則運行了1.93秒.
    我原以為這也許只是語言或者編譯器的不一樣的問題,所以我又用Java試了一下。

以下是Java程式碼段

import java.util.Arrays;
import java.util.Random;

public class Main
{
    public static void main(String[] args)
    {
        // Generate data
        int arraySize = 32768;
        int data[] = new int[arraySize];

        Random rnd = new Random(0);
        for (int c = 0; c < arraySize; ++c)
            data[c] = rnd.nextInt() % 256;

        // !!! With this, the next loop runs faster
        Arrays.sort(data);

        // Test
        long start = System.nanoTime();
        long sum = 0;

        for (int i = 0; i < 100000; ++i)
        {
            // Primary loop
            for (int c = 0; c < arraySize; ++c)
            {
                if (data[c] >= 128)
                    sum += data[c];
            }
        }

        System.out.println((System.nanoTime() - start) / 1000000000.0);
        System.out.println("sum = " + sum);
    }
}

結果相似,沒有很大的差別。


我首先得想法是排序把資料放到了cache中,但是我下一個想法是我之前的想法是多麼傻啊,因為這個陣列剛剛被構造。

  • 到底這是為什麼呢?
  • 為什麼排序的陣列會快於沒有排序的陣列?
  • 這段程式碼是為了求一些無關聯的資料的和,排不排序應該沒有關係啊。

回答

什麼是分支預測?

看看這個鐵路分岔口

Image by Mecanismo, via Wikimedia Commons. Used under the CC-By-SA 3.0 license.

為了理解這個問題,想象一下,如果我們回到19世紀.

你是在分岔口的操作員。當你聽到列車來了,你沒辦法知道這兩條路哪一條是正確的。然後呢,你讓列車停下來,問列車員哪條路是對的,然後你才轉換鐵路方向。

火車很重有很大的慣性。所以他們得花費很長的時間開車和減速。

是不是有個更好的辦法呢?你猜測哪個是火車正確的行駛方向

  • 如果你猜對了,火車繼續前行
  • 如果你猜錯了,火車得停下來,返回去,然後你再換條路。

如果你每次都猜對了,那麼火車永遠不會停下來。
如果你猜錯太多次,那麼火車會花費很多時間來停車,返回,然後再啟動


考慮一個if條件語句:在處理器層面上,這是一個分支指令:

當處理器看到這個分支時,沒辦法知道哪個將是下一條指令。該怎麼辦呢?貌似只能暫停執行,直到前面的指令完成,然後再繼續執行正確的下一條指令?
現代處理器很複雜,因此它需要很長的時間"熱身"、"冷卻"

是不是有個更好的辦法呢?你猜測下一個指令在哪!

  • 如果你猜對了,你繼續執行。
  • 如果你猜錯了,你需要flush the pipeline,返回到那個出錯的分支,然後你才能繼續。

如果你每次都猜對了,那麼你永遠不會停
如果你猜錯了太多次,你就要花很多時間來滾回,重啟。


這就是分支預測。我承認這不是一個好的類比,因為火車可以用旗幟來作為方向的標識。但是在電腦中,處理器不能知道哪一個分支將走到最後。

所以怎樣能很好的預測,儘可能地使火車必須返回的次數變小?你看看火車之前的選擇過程,如果這個火車往左的概率是99%。那麼你猜左,反之亦然。如果每3次會有1次走這條路,那麼你也按這個三分之一的規律進行。

換句話說,你試著定下一個模式,然後按照這個模式去執行。這就差不多是分支預測是怎麼工作的。

大多數的應用都有很好的分支預測。所以現代的分支預測器通常能實現大於90%的命中率。但是當面對沒有模式識別、無法預測的分支,那分支預測基本就沒用了。

如果你想知道更多:Branch predictor" article on Wikipedia.


有了前面的說明,問題的來源就是這個if條件判斷語句

if (data[c] >= 128)
    sum += data[c];

注意到資料是分佈在0到255之間的。當資料排好序後,基本上前一半大的的資料不會進入這個條件語句,而後一半的資料,會進入該條件語句.

連續的進入同一個執行分支很多次,這對分支預測是非常友好的。可以更準確地預測,從而帶來更高的執行效率。

快速理解一下
T = branch taken
N = branch not taken

data[] = 0, 1, 2, 3, 4, ... 126, 127, 128, 129, 130, ... 250, 251, 252, ...
branch = N  N  N  N  N  ...   N    N    T    T    T  ...   T    T    T  ...

       = NNNNNNNNNNNN ... NNNNNNNTTTTTTTTT ... TTTTTTTTTT  (easy to predict)

但是當資料是完全隨機的,分支預測就沒什麼用了。因為他無法預測隨機的資料。因此就會有大概50%的概率預測出錯。

data[] = 226, 185, 125, 158, 198, 144, 217, 79, 202, 118,  14, 150, 177, 182, 133, ...
branch =   T,   T,   N,   T,   T,   T,   T,  N,   T,   N,   N,   T,   T,   T,   N  ...

       = TTNTTTTNTNNTTTN ...   (completely random - hard to predict)

我們能做些什麼呢

如果編譯器無法優化帶條件的分支,如果你願意犧牲程式碼的可讀性換來更好的效能的話,你可以用下面的一些技巧。

if (data[c] >= 128)
    sum += data[c];

替換成

int t = (data[c] - 128) >> 31;
sum += ~t & data[c];

這消滅了分支,把它替換成按位操作.

(說明:這個技巧不是非常嚴格的等同於原來的if條件語句。但是在data[]當前這些值下是OK的)

使用的裝置引數是:Core i7 920 @ 3.5 GHz
C++ - Visual Studio 2010 - x64 Release

//  Branch - Random
seconds = 11.777

//  Branch - Sorted
seconds = 2.352

//  Branchless - Random
seconds = 2.564

//  Branchless - Sorted
seconds = 2.587

Java - Netbeans 7.1.1 JDK 7 - x64

//  Branch - Random
seconds = 10.93293813

//  Branch - Sorted
seconds = 5.643797077

//  Branchless - Random
seconds = 3.113581453

//  Branchless - Sorted
seconds = 3.186068823

結論:

  • 用了分支(if):沒有排序和排序的資料,效率有很大的區別
  • 用了上面提到的按位操作替換:排序與否,效率沒有很大的區別
  • 在使用C++的情況下,按位操作還是要比排好序的分支操作要慢。

一般的建議是儘量避免在關鍵迴圈上出現對資料很依賴的分支。(就像這個例子)


更新:

  • GCC 4.6.1 用了 -O3 or -ftree-vectorize,在64位機器上,資料有沒有排序,都是一樣快。
    ...
    ...
    ...等各種例子

說明了現代編譯器越發成熟強大,可以在這方面充分優化程式碼的執行效率

相關內容

CPU的流水線指令執行

想象現在有一堆指令等待CPU去執行,那麼CPU是如何執行的呢?具體的細節可以找一本計算機組成原理來看。CPU執行一堆指令時,並不是單純地一條一條取出來執行,而是按照一種流水線的方式,在CPU真正指令前,這條指令就像工廠裡流水線生產的產品一樣,已經被經過一些處理。簡單來說,一條指令可能經過過程:取指(Fetch)、解碼(Decode)、執行(Execute)、放回(Write-back)。

假設現在有指令序列ABCDEFG。當CPU正在執行(execute)指令A時,CPU的其他處理單元(CPU是由若干部件構成的)其實已經預先處理到了指令A後面的指令,例如B可能已經被解碼,C已經被取指。這就是流水線執行,這可以保證CPU高效地執行指令。

分支預測

如上所說,CPU在執行一堆順序執行的指令時,因為對於執行指令的部件來說,其基本不需要等待,因為諸如取指、解碼這些過程早就被做了。但是,當CPU面臨非順序執行的指令序列時,例如之前提到的跳轉指令,情況會怎樣呢?

取指、解碼這些CPU單元並不知道程式流程會跳轉,只有當CPU執行到跳轉指令本身時,才知道該不該跳轉。所以,取指解碼這些單元就會繼續取跳轉指令之後的指令。當CPU執行到跳轉指令時,如果真的發生了跳轉,那麼之前的預處理(取指、解碼)就白做了。這個時候,CPU得從跳轉目標處臨時取指、解碼,然後才開始執行,這意味著:CPU停了若干個時鐘週期!

這其實是個問題,如果CPU的設計放任這個問題,那麼其速度就很難提升起來。為此,人們發明了一種技術,稱為branch prediction,也就是分支預測。分支預測的作用,就是預測某個跳轉指令是否會跳轉。而CPU就根據自己的預測到目標地址取指令。這樣,即可從一定程度提高執行速度。當然,分支預測在實現上有很多方法。

stackoverflow連結:

這個問題的所有回答中,最高的回答,獲取了上萬個vote,還有很多個回答,非常瘋狂,大家覺得不過癮可以移步到這裡檢視

http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array

  • 引用於 https://github.com/giantray/stackoverflow-java-top-qa

歡迎關注 http://yunlongn.github.io