快速排序对 CPU 缓存“友好”吗？答案

【问题标题】：Is quicksort "friendly" to on-CPU caches?快速排序对 CPU 缓存“友好”吗？
【发布时间】：2016-01-18 09:34:23
【问题描述】：

假定要排序的数组比 CPU 上最大的缓存大得多（至少大两个数量级）。

由于快速排序涉及将高于枢轴的值移动到枢轴之上，反之亦然反之亦然，我想它在排序的开始阶段对 CPU 缓存不是很友好？

在后期（小型子阵列）它可能是缓存友好的，但初始阶段的成本呢？

有没有人计算过一些关于缓存未命中和缓存命中的成本以及它如何影响快速排序的总体成本的公式？

【问题讨论】：

已经有大量关于缓存效果和排序的学术研究，很容易搜索到。这只是一个，感谢谷歌的感觉幸运按钮：diku.dk/forskning/performance-engineering/frederik
How is quicksort is related to cache?的可能重复

【解决方案1】：

高性能语言中的典型排序算法不会像理论所暗示的那样在一个元素处停止递归，而是作为 2^N 个元素（16 个左右）停止递归，以便在最后阶段使用硬编码排序。这使缓存行内的排序保持高效。

不过，在初始阶段，两个元素是相隔 200 个还是 20000 个元素并不重要。无论哪种方式，它们都位于不同的缓存行上。

【讨论】：

“它们都在不同的缓存行上。”我理解这一点，但是由于每个递归分区一遍又一遍地触及每个内存位置（比如在数组中间的枢轴，第一个分区，迭代所有键；第二个分区，2个递归调用再次触及枢轴上方和下方的每个内存位置，等等)，这不会导致一遍又一遍地覆盖（LRU 删除？）相同的内存位置缓存值吗？如果特定的快速排序需要 N 个分区并且数组比缓存大得多，这意味着几乎 N 次重新获取每个缓存值。
@LetMeSOThat4U：但是，它不会在分区内跳跃；它线性扫描分区（通常是向前和向后，但仍然是线性的）。此外，到达 N/4 所需的递归次数与从 N/4 到 N/16 的次数完全相同，但第二组递归（以及所有后续递归）完全在 N/4 分区内。所以它并不是真的“几乎 N”。