既然现代机器都是多核心的，而且我们支持在SSE指令下的Windows和Linux机器上的SIMD指令，例如，我应该在我的C / C ++代码中切换到合并sorting并忘记了QuickSort？ 从理论上讲，这样做的理由是合并sorting会更好地并行化，并更加节省地使用内存/磁盘，因此比QuickSort的内存密集型操作更快，但我不知道。 实际经验表明什么？
我不想在每次sorting时进行configuration和testing。 我想用一个标准的方法。 目前该方法是QuickSort，因为这是默认的库sorting例程。 我想知道是否有其他人切换到MergeSort并通过切换获得更好的结果。
UPDATE ————
Graham.Reeds回答在实践中，std :: sort和std :: stable_sort之间的性能差距有多大？ 表明我上面的猜测是正确的，切换到MergeSort / stablesort可能是正确的。
在得到很多不答复之后，我花了几个小时做了自己的研究。 这样做的结果是，合并排序（和其他相关的排序）将会因为内存使用的不足而更快，以及更好的并行/多核开发。 此外，英特尔还有一个称为IPP的标准高性能库，用于x86机器的合并式分类。 通过切换到这个库看起来像我可以大大改善排序性能（和其他矢量类型的操作）我编程的类型。
我不认为有一个明确的答案。 在某些情况下，并行蛮力排序可能会更快。 分析你的具体情况总是很重要的。 例如，如果你有多个核和SIMD，也考虑一下这种双向排序。
我应该切换到我的C / C ++代码合并排序，并忘记QuickSort？
抱歉说这个，但这个问题听起来像是一个尝试过早的优化。
从理论上讲，这样做的理由是合并排序会更好地并行化，并更加节省地使用内存/磁盘，因此比QuickSort的内存密集型操作更快，但我不知道。 实际经验表明什么？
实际上，您应该总是首先进行分析，然后根据结果确定优化领域。
很有可能你甚至不需要改变你使用的排序算法，除非你通过一个足够大的数据集来处理结果（或者在处理流程足够关键的区域）。
我通常使用std :: sort，如果这还不够（对于std::sort ，还没有发生），我优化了我的应用程序流和算法。
事实是，你必须自己分析它，看看它是如何表现你的应用程序，数据，环境等。这本质上是对类似于SO上所有性能分析/性能/优化问题的99％的答案。
有一些并行排序软件包可以根据处理器内核的数量进行扩展，并设计为利用/优化每个处理器上的处理。 我知道TBB（线程构建模块）有一个parallel_sort函数，它是一个平均时间复杂度为0（n log n）的比较排序。
你也可以在快速排序中实现一些线程。 在TBB中，使用parallel_for可以轻松地将递归函数转换为并行性，或者您可以查看Cilk Plus，网上有很多线程示例。