并行快速排序 boost::thread答案

【问题标题】：parallel quicksort boost::thread并行快速排序 boost::thread
【发布时间】：2012-03-12 00:56:33
【问题描述】：

我编写了快速排序算法的就地实现，它的表现非常出色（1024 个元素为 0.8 毫秒）。我想如果我在多个线程上实现它可以让它执行得更快，所以我尝试使用 boost::thread 并且列表排序完美，但它比我的顺序版本（1539.3ms）长了 1500 倍。我尝试将线程数限制为各种数字，但似乎没有什么能像原始版本一样快。为什么会出现这种情况？有人成功实现了并行就地快速排序吗？

【问题讨论】：

您多久创建一次线程？您正在使用多少个线程？我的赌注：创建线程和同步它们的成本大于回报。
我有一个最大线程数，例如 4 个，如果正在运行的线程数少于 4 个，我会在每次拆分数组时打开一个新线程。
这是一个获得有用数据点的练习：采用多线程代码，但将线程数限制设置为 1。
一个需要考虑的问题：当两个不同的线程修改位置相似的内存时，一些计算机架构真的不喜欢它。
最后一条评论——试图优化一个占用程序运行时间 0.8 毫秒的例程是浪费精力（除了智力练习）。尝试优化一个执行一百万次的例程会很有用，但是您有一个明显的并行性来源：将您的线程设置为在完全不同的数组上工作。

标签： c++ multithreading boost quicksort

【解决方案1】：

一般建议：

不要并行化小型工作负载，它不会起作用（只需尝试测量操作系统创建新线程所需的时间，将其与您的 8 毫秒进行比较）。你低估了这个成本。
- 每个不同的线程仍应有相当大的工作负载，否则回退到单线程。
如果可能，不要锁定。如果您锁定，您只是让 CPU 有机会什么都不做。
不要在不同的线程上共享数据。那是：
- 首先不要访问相同的数据进行写入（从不）
- 不要访问内存中“关闭”的数据（虚假共享效应）
使用任务库而不是线程（boost.threadpool 是我喜欢的，但也有其他同样出色的）。
- 不要杀死创建的线程，让它们等待更多的工作
运行的线程数不要超过处理器数（如果您有超线程或类似处理器，则为逻辑处理器）。
使用 CPU 亲和性来锁定给定内核上的线程（具体如何取决于您的操作系统）。

编辑：尝试使用 100 万个元素或其他元素，因为 1000 个真的很小。然后尝试绘制每个线程的效率与数组大小的曲线。

【讨论】：

顺序版本需要 2621.8 ms 处理 1000000 个元素，多线程版本在 4 到 5 秒后崩溃
@PgrAm：如果它崩溃了，那么它就是错误的——这个错误可能会也可能不会导致浪费的时间。修复它，然后告诉我们它有多快/多慢......