C++ 并行快速排序boost:：thread

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

一般建议：

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

---

编辑：尝试使用100万个元素，因为1000个元素非常小。然后尝试绘制每个线程的效率与阵列大小的曲线。

创建线程的频率是多少？你使用了多少线程？我打赌：创建线程和同步线程的成本比回报更高。我有一个最大线程数，例如4个，如果运行的线程数少于4个，我会在每次拆分数组时打开一个新的线程。下面是一个获取有用数据点的练习：获取多线程代码，但是，将线程数限制为1。需要考虑的一个问题是：当两个不同的线程修改相同位置的内存时，某些计算机体系结构确实不喜欢这样。最后一条评论——尝试优化一个占用程序运行时间0.8毫秒的例程是一种浪费（除非是作为智力练习）。尝试优化一个执行此操作一百万次的例程可能会很有用，但这里有一个明显的并行性来源：将线程设置为在完全不同的数组上工作。连续的线程需要2621.8毫秒才能处理1000000个元素，而多线程版本在处理4到5次后崩溃seconds@PgrAm：如果它崩溃，然后就是buggy——这个bug可能会也可能不会解释浪费的时间。修好它，然后告诉我们它有多快/慢。。。。