Arrays 合并排序--按缓存线大小进行优化？
我的一个朋友最近提到，可以通过“缩短”来减少合并排序的实时运行时间。他提到，您不应该将阵列分解为各个块，而应该在各个阵列大小等于缓存线大小的位置停止，因为整个阵列将加载到缓存中。此时，应使用替代排序（即插入排序）合并每个数组，然后完成合并排序 虽然BigO提出了相反的建议，但他的建议似乎有直观的意义。有人能证实或否认这一点，和/或提供更多关于这一点如何以及为什么起作用的信息吗 谢谢你们的帮助 答案（有点抽象）是大O只对大数有用：它抛弃了常数因子：O（n）=O（3n），它抛弃了低阶项：O（n²+3n）=O（n²）。所以是的，你不能从大O符号中分辨出来 此外，Big-O表示法通常用于一个非常简单的模型，其中每个“操作”只需花费1美元，它不知道缓存Arrays 合并排序--按缓存线大小进行优化？,arrays,sorting,caching,mergesort,insertion-sort,Arrays,Sorting,Caching,Mergesort,Insertion Sort,我的一个朋友最近提到，可以通过“缩短”来减少合并排序的实时运行时间。他提到，您不应该将阵列分解为各个块，而应该在各个阵列大小等于缓存线大小的位置停止，因为整个阵列将加载到缓存中。此时，应使用替代排序（即插入排序）合并每个数组，然后完成合并排序 虽然BigO提出了相反的建议，但他的建议似乎有直观的意义。有人能证实或否认这一点，和/或提供更多关于这一点如何以及为什么起作用的信息吗 谢谢你们的帮助 答案（有点抽象）是大O只对大数有用：它抛弃了常数因子：O（n）=O（3n），它抛弃了低阶项：O（n²+3
这就是为什么模型没有告诉你这可能有用的原因。我想你可以看看Donald E.Knuth的“排序和搜索”，他在一种虚构的汇编语言上进行运行时分析（但仍然没有考虑缓存，IIRC）。插入排序组合创建小运行，然后切换到合并排序称为timsort。维基文章：
使用O（Ω、Θ等）分析复杂性只是为了描述算法在输入大小增加时的性能。如果你看一下实际的函数，你会发现随着输入的增加，常数因子变得不那么重要了。总的来说，输入大小决定了功能 但在实践中，常量因素确实很重要（缓存未命中、指令延迟等），这就是通常很少使用的原因。例如，从寄存器读取大约需要从缓存中的最低级别读取的1/5时间（即下一级别的1/5时间，以此类推）。由于它们是数量级，在实践中，缓存成本通常会主导算法的实际性能
插入排序确实相当有效地使用缓存，通常只要数据适合缓存。因为它是连续的，所以它也能与预测器很好地交互。这两个原因通常都是较小的输入更好的原因。另一个很好的例子是，它在技术上是
O（n^2）std:：sort