web-dev-qa-db-ja.com

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

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

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

ランダム配列を生成し、xのランダムに生成された100個の値に対して検索を実行すると、検索は約4秒で完了します。 ソートが検索に役立つのは素晴らしいことです を知っているので、データをソートすることにしました-最初にItem1、次にItem2、最後にItem3-100回の検索を実行する前。分岐予測のためにソートされたバージョンの実行が少し速くなると予想していました。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)
c#.netperformancelanguage-agnostic
230
dasblinkenlight

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

リストをソートするときは、ソートキーがランダムに生成されるため、リストをrandom orderに配置します。これは、Tupleメンバーへのメモリアクセスが予測不能であることを意味します。 CPUはメモリをプリフェッチできず、タプルへのほとんどすべてのアクセスはキャッシュミスです。

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

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

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

Chris Sinclairは、コメントで "TotalCountが約10,000以下の場合、ソートされたバージョンはより高速に実行します"と述べています。これは、小さなリストCPUキャッシュに完全に適合するであるためです。メモリアクセスは予測不能ですが、ターゲットは常にキャッシュにあります。キャッシュからのロードでさえ数サイクルかかるため、まだ小さなペナルティがあると思います。しかし、CPUは複数の未処理の負荷を処理できるであるため、それは問題ではないと思われます。 CPUがメモリの待機をヒットするたびに、可能な限り多くのメモリ操作をキューに入れるために、命令ストリームで先に進みます。この手法は、待ち時間を隠すために使用されます。

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

264
usr

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

述語パラメーター付きのCountは、すべてのIEnumerablesの拡張メソッドであるため、効率的なランダムアクセスでコレクション上で実行されているかどうかさえわからないと思います。そのため、単にすべての要素をチェックし、パフォーマンスが低下した理由をsrで説明しました。

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

3
Emperor Orionii