web-dev-qa-db-ja.com

ソートされた配列の「==」は、ソートされていない配列よりも高速ではありませんか？

注：申し立てられた重複する質問は、主に「<」と「>」の比較に関連していると思いますが、「==」の比較には関連していないため、「==」演算子のパフォーマンスに関する私の質問には答えません。 。

長い間、ソートされた配列の「処理」は、ソートされていない配列よりも高速である必要があると私は信じてきました。最初は、分岐予測がどのように機能するかについて、ソートされた配列で「==」を使用する方が、ソートされていない配列よりも高速であるはずだと思いました。

UNSORTEDARRAY：

5 == 100 F
43 == 100 F
100 == 100 T
250 == 100 F
6 == 100 F
(other elements to check)

SORTEDARRAY：

5 == 100 F
6 == 100 F
43 == 100 F
100 == 100 T
(no need to check other elements, so all are F)

したがって、SORTEDARRAYはUNSORTEDARRAYよりも高速であるはずですが、今日はコードを使用してヘッダーに2つの配列を生成してテストしましたが、分岐予測は思ったように機能しなかったようです。

テストするために、ソートされていない配列とソートされた配列を生成しました。

srand(time(NULL));
int UNSORTEDARRAY[524288];
int SORTEDARRAY[sizeof(UNSORTEDARRAY)/sizeof(int)];
for(int i=0;i<sizeof(SORTEDARRAY)/sizeof(int);i++){
    SORTEDARRAY[i]=UNSORTEDARRAY[i]=Rand();
}
sort(SORTEDARRAY,SORTEDARRAY+sizeof(SORTEDARRAY)/sizeof(int));
string u="const int UNSORTEDARRAY[]={";
string s="const int SORTEDARRAY[]={";
for(int i=0;i<sizeof(UNSORTEDARRAY)/sizeof(int);i++){
    u+=to_string(UNSORTEDARRAY[i])+",";
    s+=to_string(SORTEDARRAY[i])+",";
}
u.erase(u.end()-1);
s.erase(s.end()-1);
u+="};\n";
s+="};\n";
ofstream out("number.h");
string code=u+s;
out << code;
out.close();

したがって、テストするには、次のように値が== Rand_MAX/2であるかどうかを数えます。

#include "number.h"
int main(){
int count;
    clock_t start = clock();
    for(int i=0;i<sizeof(SORTEDARRAY)/sizeof(int);i++){
        if(SORTEDARRAY[i]==Rand_MAX/2){
            count++;
        }
    }
    printf("%f\n",(float)(clock()-start)/CLOCKS_PER_SEC);
}

3回実行：

UNSORTEDARRAY

0.005376
0.005239
0.005220

SORTEDARRAY

0.005334
0.005120
0.005223

パフォーマンスのわずかな違いのように思われるので、信じられなかったので、「SORTEDARRAY [i] == Rand_MAX/2」を「SORTEDARRAY [i]> Rand_MAX/2」に変更して、違いが生じるかどうかを確認しました。

UNSORTEDARRAY

0.008407
0.008363
0.008606

SORTEDARRAY

0.005306
0.005227
0.005146

今回は大きな違いがあります。

ソートされた配列の「==」は、ソートされていない配列よりも高速ではありませんか？はいの場合、ソートされた配列の ">"がソートされていない配列よりも速いのに、 "=="はそうではないのはなぜですか？

carraysperformanceoptimizationsortedlist
42
ggrr

すぐに頭に浮かぶのは、CPUの分岐予測アルゴリズムです。

>比較の場合、ソートされた配列では、分岐動作は非常に一貫しています。最初に、if条件は一貫して偽であり、次に一貫して真です。これは、最も単純な分岐予測と非常によく一致します。

ソートされていない配列では、>条件の結果は本質的にランダムであるため、分岐予測が妨げられます。

これにより、ソートされたバージョンが高速になります。

==比較の場合、ほとんどの場合、条件はfalseであり、trueになることはめったにありません。これは、配列がソートされているかどうかに関係なく、分岐予測でうまく機能します。タイミングは基本的に同じです。

28
AnT

N.B.コメントするには長すぎるので、私はこれを答えにしています。

ここでの効果は、 この質問 に対する豊富な回答ですでに詳細に説明されているものです。その場合、分岐予測により、ソートされた配列の処理が高速になりました。

ここでも、原因は分岐予測です。 ==テストが真になることはめったにないため、分岐予測は両方でほぼ同じように機能します。 >に変更すると、同じ理由で、その質問で説明されている動作が得られます。

道徳の：

ソートされた配列の「処理」は、ソートされていない配列よりも高速である必要があると思います。

あなたはなぜを知る必要があります。これは魔法のルールではなく、常に正しいとは限りません。

12
imallett

比較==は、>よりも順序付けとの関係が少なくなっています。 ==を正しくまたは誤って予測することは、重複する値の数とその分布にのみ依存します。

perf statを使用してパフォーマンスカウンターを表示できます...

jason@io /tmp $ lz4 -d ints | perf stat ./proc-eq >/dev/null
Successfully decoded 104824717 bytes

 Performance counter stats for './proc-eq':

       5226.932577      task-clock (msec)         #    0.953 CPUs utilized
                31      context-switches          #    0.006 K/sec
                24      cpu-migrations            #    0.005 K/sec
             3,479      page-faults               #    0.666 K/sec
    15,763,486,767      cycles                    #    3.016 GHz
     4,238,973,549      stalled-cycles-frontend   #   26.89% frontend cycles idle
   <not supported>      stalled-cycles-backend
    31,522,072,416      instructions              #    2.00  insns per cycle
                                                  #    0.13  stalled cycles per insn
     8,515,545,178      branches                  # 1629.167 M/sec
        10,261,743      branch-misses             #    0.12% of all branches

       5.483071045 seconds time elapsed

jason@io /tmp $ lz4 -d ints | sort -n | perf stat ./proc-eq >/dev/null
Successfully decoded 104824717 bytes

 Performance counter stats for './proc-eq':

       5536.031410      task-clock (msec)         #    0.348 CPUs utilized
               198      context-switches          #    0.036 K/sec
                21      cpu-migrations            #    0.004 K/sec
             3,604      page-faults               #    0.651 K/sec
    16,870,541,124      cycles                    #    3.047 GHz
     5,300,218,855      stalled-cycles-frontend   #   31.42% frontend cycles idle
   <not supported>      stalled-cycles-backend
    31,526,006,118      instructions              #    1.87  insns per cycle
                                                  #    0.17  stalled cycles per insn
     8,516,336,829      branches                  # 1538.347 M/sec
        10,980,571      branch-misses             #    0.13% of all branches

jason@io /tmp $ lz4 -d ints | perf stat ./proc-gt >/dev/null
Successfully decoded 104824717 bytes

 Performance counter stats for './proc-gt':

       5293.065703      task-clock (msec)         #    0.957 CPUs utilized
                38      context-switches          #    0.007 K/sec
                50      cpu-migrations            #    0.009 K/sec
             3,466      page-faults               #    0.655 K/sec
    15,972,451,322      cycles                    #    3.018 GHz
     4,350,726,606      stalled-cycles-frontend   #   27.24% frontend cycles idle
   <not supported>      stalled-cycles-backend
    31,537,365,299      instructions              #    1.97  insns per cycle
                                                  #    0.14  stalled cycles per insn
     8,515,606,640      branches                  # 1608.823 M/sec
        15,241,198      branch-misses             #    0.18% of all branches

       5.532285374 seconds time elapsed

jason@io /tmp $ lz4 -d ints | sort -n | perf stat ./proc-gt >/dev/null

      15.930144154 seconds time elapsed

 Performance counter stats for './proc-gt':

       5203.873321      task-clock (msec)         #    0.339 CPUs utilized
                 7      context-switches          #    0.001 K/sec
                22      cpu-migrations            #    0.004 K/sec
             3,459      page-faults               #    0.665 K/sec
    15,830,273,846      cycles                    #    3.042 GHz
     4,456,369,958      stalled-cycles-frontend   #   28.15% frontend cycles idle
   <not supported>      stalled-cycles-backend
    31,540,409,224      instructions              #    1.99  insns per cycle
                                                  #    0.14  stalled cycles per insn
     8,516,186,042      branches                  # 1636.509 M/sec
        10,205,058      branch-misses             #    0.12% of all branches

      15.365528326 seconds time elapsed
6
Jason