ソートされた配列の処理がソートされていない配列よりも遅いのはなぜですか？

Tuple<long,long,string>単純な「間」の検索を実行する500000個のランダムに生成されたオブジェクトのリストがあります。

var data = new List<Tuple<long,long,string>>(500000);
...
var cnt = data.Count(t => t.Item1 <= x && t.Item2 >= x);

ランダムな配列を生成し、ランダムに生成された100個のの値に対して検索を実行すると、検索xは約4秒で完了します。並べ替えが検索に与える大きな驚異を知っていたため、100回の検索を実行する前に、データを最初にItem1、次にItem2、最後にの順に並べ替えることにしましたItem3。分岐予測のため、ソートされたバージョンのパフォーマンスが少し速くなることを期待していました：のポイントに到達するとItem1 == x、のすべてのチェックでt.Item1 <= x分岐が「ノーテイク」と正しく予測され、のテール部分が高速になると考えていました探す。驚いたことに、ソートされた配列の検索には2倍の時間がかかりました。

実験を実行する順序を切り替えてみて、乱数ジェネレーターに別のシードを使用しましたが、効果は同じです。並べ替えられていない配列での検索は、同じ配列での検索のほぼ2倍の速度で実行されましたが、ソートされました！

誰かがこの奇妙な効果をうまく説明していますか？私のテストのソースコードは次のとおりです。.NET 4.0を使用しています。

private const int TotalCount = 500000;
private const int TotalQueries = 100;
private static long NextLong(Random r) {
    var data = new byte[8];
    r.NextBytes(data);
    return BitConverter.ToInt64(data, 0);
}
private class TupleComparer : IComparer<Tuple<long,long,string>> {
    public int Compare(Tuple<long,long,string> x, Tuple<long,long,string> y) {
        var res = x.Item1.CompareTo(y.Item1);
        if (res != 0) return res;
        res = x.Item2.CompareTo(y.Item2);
        return (res != 0) ? res : String.CompareOrdinal(x.Item3, y.Item3);
    }
}
static void Test(bool doSort) {
    var data = new List<Tuple<long,long,string>>(TotalCount);
    var random = new Random(1000000007);
    var sw = new Stopwatch();
    sw.Start();
    for (var i = 0 ; i != TotalCount ; i++) {
        var a = NextLong(random);
        var b = NextLong(random);
        if (a > b) {
            var tmp = a;
            a = b;
            b = tmp;
        }
        var s = string.Format("{0}-{1}", a, b);
        data.Add(Tuple.Create(a, b, s));
    }
    sw.Stop();
    if (doSort) {
        data.Sort(new TupleComparer());
    }
    Console.WriteLine("Populated in {0}", sw.Elapsed);
    sw.Reset();
    var total = 0L;
    sw.Start();
    for (var i = 0 ; i != TotalQueries ; i++) {
        var x = NextLong(random);
        var cnt = data.Count(t => t.Item1 <= x && t.Item2 >= x);
        total += cnt;
    }
    sw.Stop();
    Console.WriteLine("Found {0} matches in {1} ({2})", total, sw.Elapsed, doSort ? "Sorted" : "Unsorted");
}
static void Main() {
    Test(false);
    Test(true);
    Test(false);
    Test(true);
}

Populated in 00:00:01.3176257
Found 15614281 matches in 00:00:04.2463478 (Unsorted)
Populated in 00:00:01.3345087
Found 15614281 matches in 00:00:08.5393730 (Sorted)
Populated in 00:00:01.3665681
Found 15614281 matches in 00:00:04.1796578 (Unsorted)
Populated in 00:00:01.3326378
Found 15614281 matches in 00:00:08.6027886 (Sorted)

ソートされていないリストを使用している場合、すべてのタプルはmemory-orderでアクセスされます。それらはRAMに連続して割り当てられています。CPUは、次のキャッシュラインを投機的に要求できるため、必要に応じて常に存在するため、メモリへの順次アクセスが大好きです。

リストをソートするときは、ソートキーがランダムに生成されるため、リストをランダムな順序に並べます。つまり、タプルメンバーへのメモリアクセスは予測不可能です。CPUはメモリをプリフェッチできず、タプルへのほとんどすべてのアクセスはキャッシュミスです。

これは、GCメモリ管理の特定の利点の良い例です。一緒に割り当てられ、一緒に使用されるデータ構造は、非常にうまく機能します。彼らは偉大な参照の局所性を持っています。

この場合、キャッシュミスによるペナルティは、保存された分岐予測ペナルティを上回ります。

struct-tupleに切り替えてみてください。実行時にタプルメンバーにアクセスするためにポインター逆参照を行う必要がないため、これによりパフォーマンスが復元されます。

Chris Sinclairは、コメントの中で「TotalCountが約10,000以下の場合、ソートされたバージョンはより高速に実行される」と述べています。これは、小さなリストが完全にCPUキャッシュに収まるためです。メモリアクセスは予測できない場合がありますが、ターゲットは常にキャッシュ内にあります。キャッシュからのロードでさえもいくつかのサイクルを要するため、ペナルティはまだ小さいと思います。ただし、CPUは複数の未解決の負荷を調整し、それによってスループットを向上させることができるため、これは問題ではないようです。CPUがメモリの待機にヒットするときはいつでも、CPUは命令ストリーム内でさらに速度を上げて、できるだけ多くのメモリ操作をキューに入れます。この手法は、待ち時間を隠すために使用されます。

この種の動作は、最新のCPUでパフォーマンスを予測することがいかに難しいかを示しています。シーケンシャルメモリからランダムメモリへのアクセスが2倍遅いだけであるという事実は、メモリレイテンシを隠すために内部でどれだけのことが行われているのかを教えてくれます。メモリアクセスは、CPUを50〜200サイクル停止させる可能性があります。ランダムメモリアクセスを導入すると、プログラムの速度が10倍以上になることが予想されます。

LINQは、リストがソートされているかどうかを認識しません。

述語パラメーター付きのCountはすべてのIEnumerableの拡張メソッドであるため、効率的なランダムアクセスでコレクションを実行しているかどうかもわかりません。そのため、すべての要素をチェックし、パフォーマンスが低下した理由をUsrが説明しました。

ソートされた配列（バイナリ検索など）のパフォーマンス上の利点を活用するには、もう少しコーディングを行う必要があります。