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

我有一个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值时,搜索大约在4秒内完成。知道了排序对搜索的巨大作用,然而,我决定对我的数据进行排序——首先是Item1,然后是Item2,最后是Item3——在运行我的100次搜索之前。由于分支预测,我期望排序版本执行得稍微快一点:我的想法是,一旦我们到达Item1 == x,所有对t.Item1 <= x的进一步检查都将正确地预测分支为“no take”,从而加快搜索的尾部部分。令我惊讶的是,在一个排序的数组上,搜索需要两倍的时间!

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

有人能很好地解释这个奇怪的效应吗?下面是我测试的源代码;我使用的是。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)
12167 次浏览

当使用无序列表时,所有元组都在记忆点中访问。它们被连续地分配到RAM中。cpu喜欢按顺序访问内存,因为它们可以推测地请求下一条缓存线,以便在需要时始终存在。

当你对列表排序时,你把它放在随机的顺序中,因为你的排序键是随机生成的。这意味着对元组成员的内存访问是不可预测的。CPU不能预取内存,几乎每次对元组的访问都是缓存丢失。

这是一个很好的例子,说明了GC内存管理的一个特殊优势:一起分配和一起使用的数据结构执行得非常好。他们有很棒的参考地点

在这种情况下,缓存的惩罚会错过超过保存的分支预测惩罚

尝试切换到struct-tuple。这将恢复性能,因为在运行时不需要进行指针解引用来访问元组成员。

Chris Sinclair在评论中指出对于TotalCount大约10,000或更少,排序版本的执行速度更快”。这是因为一个小列表完全适合CPU缓存.;内存访问可能是不可预测的,但目标始终在缓存中。我相信仍然有一个小的惩罚,因为即使从缓存加载也需要一些周期。但这似乎不是一个问题,因为CPU可以处理多个未完成的负载,从而增加了吞吐量。每当CPU到达等待内存时,它仍然会在指令流中加速前进,尽可能多地排队内存操作。该技术用于隐藏延迟。

这种行为表明,在现代cpu上预测性能是多么困难。当从顺序内存访问到随机内存访问时,我们是只是慢了2倍,这一事实告诉我在隐藏内存延迟的情况下发生了多少事情。内存访问可以使CPU停止50-200个周期。考虑到第一点,当引入随机内存访问时,程序会变慢10倍。

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

由于带有谓词参数的Count是所有IEnumerables的扩展方法,我认为它甚至不知道它是否在高效随机访问的集合上运行。因此,它只是检查每个元素,Usr解释了为什么性能变低。

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