为什么处理已排序的数组比未排序的数组慢?

250

我有一个包含500000个随机生成的Tuple<long,long,string>对象的列表,我正在对其执行简单的“between”搜索:

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

当我生成随机数组并对100个随机生成的 x 值运行搜索时,搜索大约需要四秒钟。然而,我知道排序对搜索的巨大帮助, 因此在运行我的100次搜索之前,我决定先按 Item1, 然后按 Item2, 最后按 Item3 排序我的数据。我预计排序后的版本会因为分支预测而表现得更快:我的想法是一旦我们到达 Item1 == x 的点,所有后续的 t.Item1 <= x 检查将正确地预测分支为“不取”,从而加速搜索的尾部部分。但令我惊讶的是,在排序后的数组上搜索所需时间是未排序数组的两倍! 我尝试改变实验运行的顺序,并使用了不同的随机数种子,但效果是相同的:未排序数组中的搜索几乎比排序后的数组中的搜索快了近两倍!

有人能解释一下这个奇怪的效果吗?以下是我的测试源代码;我正在使用.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)

17
由于分支预测:p - Soner Gönül
9
我原本以为经过排序后的版本会因为分支预测而表现得更快一些。我想,一旦我们到达“Item1 == x”的点,所有进一步的“t.Item1 <= x”的检查都会正确地被预测为“不采取”,从而加速搜索的尾部部分。显然,这种思路已经被残酷的现实所证明是错误的 :) - Sergey Kalinichenko
41
这个问题并不是这里已有问题的复制,不要将其视为复制问题而投票关闭。请注意。 - ThiefMaster
3
完全没有问题!这两个问题考虑了两种非常不同的情况,自然而然地得出了不同的结果。 - Sergey Kalinichenko
1
我很惊讶地发现,处理已排序的数组比处理未排序的数组要快。 - puretppc
显示剩余8条评论
2个回答

282
当您使用未排序列表时,所有元组都按内存顺序访问。它们在RAM中连续分配。CPU喜欢按顺序访问内存,因为它们可以推测性地请求下一个高速缓存行,以便在需要时始终存在。
当您对列表进行排序时,由于您的排序键是随机生成的,因此将其放入随机顺序中。这意味着对元组成员的内存访问是不可预测的。CPU无法预取内存,几乎每次访问元组都会导致缓存未命中。
这是GC内存管理的一个特定优势的很好的例子:已经一起分配并且一起使用的数据结构表现非常好。它们具有出色的本地引用性。
在这种情况下,来自缓存未命中的惩罚超过了保存的分支预测惩罚
尝试切换到struct-tuple。这将恢复性能,因为在运行时不需要进行指针解引用来访问元组成员。
克里斯·辛克莱在评论中指出,“对于TotalCount约为10,000或更少的情况,排序版本的性能确实更快”。这是因为小列表完全适合CPU缓存。内存访问可能是不可预测的,但目标始终在缓存中。我认为仍然存在一些小的惩罚,因为即使从缓存加载也需要一些周期。但这似乎不是问题,因为CPU可以处理多个未完成的加载,从而增加吞吐量。每当CPU遇到等待内存时,它仍然会在指令流中快速前进,以排队尽可能多的内存操作。这种技术用于隐藏延迟。
这种行为显示了在现代CPU上预测性能有多么困难。从顺序内存访问转换为随机内存访问时,仅慢2倍就告诉我有多少事情正在掩盖内存延迟。内存访问可能会使CPU停滞50-200个周期。鉴于这个数字,人们可以预计在引入随机内存访问时程序会变得> 10x更慢。

6
C/C++所学知识无法直接应用到C#语言的好理由是,这两种语言在某些方面有很大不同。因此,在使用C#时需要考虑到一些与C/C++不同的特性和语法规则。 - user541686
38
您可以通过将已排序的数据手动逐一复制到一个 new List<Tuple<long,long,string>>(500000) 中,并在测试该新列表之前进行确认。在这种情况下,排序测试与未排序测试一样快,这与本答案的推理相符。 - Bobson
3
非常棒,非常感谢!我创建了一个等价的 Tuple 结构体,程序开始按照我的预测表现:排序后的版本稍微快了一点。此外,未排序的版本变得快了两倍!所以使用 struct 的数字是 2 秒未排序和 1.9 秒已排序。 - Sergey Kalinichenko
2
那么我们可以从中推断出缓存未命中比分支预测错误更加严重吗?我认为是的,并且一直都这样认为。在C++中,std::vector几乎总是比std::list表现更好。 - Nawaz
4
@Mehrdad: 不是的。这也适用于 C++。即使在 C++ 中,紧凑的数据结构也很快。避免缓存未命中在 C++ 中和其他任何语言中一样重要。std::vectorstd::list 就是一个很好的例子。 - Nawaz
显示剩余7条评论

4
LINQ不知道你的列表是否已排序。
由于带有谓词参数的Count是适用于所有IEnumerable的扩展方法,我认为它甚至不知道它是否在具有高效随机访问的集合上运行。因此,它只检查每个元素,Usr解释了性能降低的原因。
要利用已排序数组的性能优势(例如二分查找),您需要进行一些额外的编码。

5
我认为你误解了这个问题:当然我不是希望CountWhere可以“某种方式”意识到我的数据已经排序,然后运行一个二分查找而不是一个普通的“检查所有”搜索。我所希望的只是由于更好的分支预测(见问题内部的链接)而带来的一些改进,但事实证明,引用的局部性大大超过了分支预测。 - Sergey Kalinichenko

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接