提问者:小点点

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


我有一个500000个随机生成的对象列表,我正在对这些对象执行简单的“between”搜索:

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

当我生成随机数组并对100个随机生成的值运行搜索时,搜索大约在四秒钟内完成。但是,由于了解到排序对搜索的巨大作用,我决定在运行100次搜索之前先按排序,然后按排序,最后按排序。由于分支预测,我希望排序后的版本执行得更快一点:我的想法是,一旦我们到达的位置,所有对的进一步检查都将正确地预测分支为“No take”,从而加快搜索的尾部。令我惊讶的是,搜索时间是排序数组的两倍!

我尝试切换我运行实验的顺序,并为随机数生成器使用不同的种子,但效果是一样的:在未排序的数组中搜索的速度几乎是在相同数组中搜索的两倍,但已排序!

有人对这种奇怪的效应有好的解释吗?我的测试的源代码如下;我使用的是.NET4.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)

共2个答案

匿名用户

当您使用未排序列表时,所有元组都是按内存顺序访问的。它们已在RAM中连续分配。CPU喜欢按顺序访问内存,因为它们可以推测性地请求下一个缓存行,这样在需要时它将始终存在。

当您对列表进行排序时,您将其按随机顺序排列,因为您的排序键是随机生成的。这意味着对元组成员的内存访问是不可预测的。CPU不能预取内存,几乎每一次对元组的访问都是一次缓存未命中。

这是一个很好的例子,说明了GC内存管理的一个特殊优点:一起分配和一起使用的数据结构性能非常好。它们有很大的参照点。

在这种情况下,缓存未命中带来的损失大于保存的分支预测损失。

null

Chris Sinclair在评论中指出,“对于大约10,000个或更少的总数,排序版本确实表现得更快”。这是因为一个小列表完全适合CPU缓存。内存访问可能不可预测,但目标始终在缓存中。我相信还是有一个小的损失,因为即使是从缓存加载也需要一些周期。但这似乎不是一个问题,因为CPU可以处理多个未完成的负载,从而提高吞吐量。每当CPU等待内存时,它仍将在指令流中加速前进,以尽可能多地排队内存操作。此技术用于隐藏延迟。

这种行为表明在现代CPU上预测性能是多么困难。从顺序到随机的内存访问,我们只慢了2倍,这一事实告诉我,隐藏内存延迟的秘密有多大。一次内存访问可以使CPU停滞50-200个周期。考虑到这一点,当引入随机内存访问时,程序可能会变得慢&>10倍。

匿名用户

LINQ不知道您的列表是否已排序。

由于Count with predicate参数是所有IEnumerables的扩展方法,我认为它甚至不知道它是否以有效的随机访问运行在集合上。因此,它简单地检查每个元素,Usr解释了性能变低的原因。

为了利用排序数组的性能优势(如二进制搜索),您必须进行更多的编码。