linux - 如果 256 个线程比 8 个线程提供更好的性能，我可能采用了错误的方法吗？

我刚刚开始在双核 x86_64 Linux 系统上使用 POSIX 线程进行编程。按照我的做法，256 个线程似乎是性能的最佳选择。我想知道这怎么可能？如果这可能意味着我的方法是错误的，而更好的方法将需要更少的线程并且同样快或更快？

有关更多背景信息(所讨论的程序是多线程 M 集图像生成器的框架)，请参阅我已经提出的以下问题:

也许我应该提到骨架(我在其中复制了用于测试和比较的最小功能)现在正在显示图像，并且实际计算的速度几乎是非线程程序的两倍。

因此，如果 256 个线程的运行速度快于 8 个线程并不表示线程处理方法不佳，那么 256 个线程的性能为何优于 8 个线程？

速度测试用例是 Mandelbrot Set 的一部分位于:

xmin -0.76243636067708333333333328
xmax -0.7624335575810185185185186
ymax 0.077996663411458333333333929

计算最多 30000 次迭代。

关于non-threaded version我系统上的渲染时间约为 15 秒。在线程版本上，8 个线程的平均速度为 7.8 秒，而 256 个线程为 7.6 秒。

最佳答案

嗯，可能是的，你做错了什么。

但是，在某些情况下，256 个线程比 8 个线程运行得更好，而线程模型不一定不好。必须记住，拥有 8 个线程并不意味着所有 8 个线程实际上一直在运行。任何时候一个线程对操作系统进行阻塞系统调用，该线程将停止运行并等待结果。与此同时，另一个线程通常可以完成工作。

有这样一种说法，即在 CPU 上使用的线程数量不能超过上下文数量，但事实并非如此。如果您的线程阻塞在系统调用上，那么让另一个线程可用于完成更多工作可能至关重要。 (实际上，当线程阻塞时，要做的工作往往会减少，但情况并非总是如此。)

这完全取决于工作负载，并且没有适合任何特定应用程序的正确线程数。通常，您永远不希望可用线程数少于操作系统运行的线程数，这是唯一正确的规则。 (不幸的是，这很难发现，因此人们倾向于启动与上下文一样多的线程，然后尽可能使用非阻塞系统调用。)

关于linux - 如果 256 个线程比 8 个线程提供更好的性能，我可能采用了错误的方法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2040036/