假设我有一个4核CPU,我想在最短的时间内运行某个进程。这个过程在理想情况下是可并行的,所以我可以在无数个线程上运行它的块,每个线程花费相同的时间。
因为我有4个内核,所以我不期望通过运行比内核更多的线程来提高速度,因为单个内核在给定时刻只能运行单个线程。我对硬件了解不多,所以这只是一个猜测。
在更多的线程而不是核心上运行并行进程是否有好处?换句话说,如果我使用4000个线程而不是4个线程运行,我的进程会更快、更慢,还是在大约相同的时间内完成?
假设我有一个4核CPU,我想在最短的时间内运行某个进程。这个过程在理想情况下是可并行的,所以我可以在无数个线程上运行它的块,每个线程花费相同的时间。
因为我有4个内核,所以我不期望通过运行比内核更多的线程来提高速度,因为单个内核在给定时刻只能运行单个线程。我对硬件了解不多,所以这只是一个猜测。
在更多的线程而不是核心上运行并行进程是否有好处?换句话说,如果我使用4000个线程而不是4个线程运行,我的进程会更快、更慢,还是在大约相同的时间内完成?
当前回答
从计算和内存限制的角度(科学计算)来说,4000个线程会让应用程序运行得非常慢。部分问题是上下文切换的开销非常高,而且很可能是内存位置非常差。
但这也取决于您的体系结构。我听说Niagara处理器应该能够使用某种先进的流水线技术在单核上处理多个线程。但是我没有使用这些处理器的经验。
其他回答
一次4000个线程是相当高的。
答案是肯定的,也不是。如果您在每个线程中执行大量阻塞I/O,那么是的,您可以在每个逻辑核心中执行3或4个线程时显示显著的加速。
If you are not doing a lot of blocking things however, then the extra overhead with threading will just make it slower. So use a profiler and see where the bottlenecks are in each possibly parallel piece. If you are doing heavy computations, then more than 1 thread per CPU won't help. If you are doing a lot of memory transfer, it won't help either. If you are doing a lot of I/O though such as for disk access or internet access, then yes multiple threads will help up to a certain extent, or at the least make the application more responsive.
从计算和内存限制的角度(科学计算)来说,4000个线程会让应用程序运行得非常慢。部分问题是上下文切换的开销非常高,而且很可能是内存位置非常差。
但这也取决于您的体系结构。我听说Niagara处理器应该能够使用某种先进的流水线技术在单核上处理多个线程。但是我没有使用这些处理器的经验。
我同意@Gonzalo的回答。我有一个不做I/O的进程,下面是我的发现:
请注意,所有线程都工作在一个数组上,但范围不同(两个线程不访问相同的索引),因此如果它们工作在不同的数组上,结果可能会有所不同。
这台1.86版本的机器是一台带有SSD的macbook air。另一台mac是一台iMac,硬盘正常(我想转速是7200转)。这台装有windows操作系统的机器还有一个7200转的硬盘。
在这个测试中,最佳的数量等于机器中的核数。
通过运行htop或ps命令(返回机器上的进程数),您将发现可以在机器上运行多少个线程。
您可以使用手册页关于'ps'命令。
man ps
如果你想计算所有用户进程的数量,你可以使用这些命令之一:
Ps -aux| wc -l ps -eLf | wc -l
计算用户进程数:
ps—root用户| wc -l
此外,你还可以使用“htop”[参考]:
在Ubuntu或Debian上安装:
sudo apt-get install htop
在Redhat或CentOS上安装:
yum install htop
dnf install htop [On Fedora 22+ releases]
如果您想从源代码编译htop,可以在这里找到它。
如果你的线程不做I/O,同步等,没有其他的运行,1个线程一个核可以让你获得最好的性能。然而,情况很可能并非如此。添加更多的线程通常会有所帮助,但在某种程度上,它们会导致性能下降。
Not long ago, I was doing performance testing on a 2 quad-core machine running an ASP.NET application on Mono under a pretty decent load. We played with the minimum and maximum number of threads and in the end we found out that for that particular application in that particular configuration the best throughput was somewhere between 36 and 40 threads. Anything outside those boundaries performed worse. Lesson learned? If I were you, I would test with different number of threads until you find the right number for your application.
有一件事是肯定的:4k线程将花费更长的时间。这有很多上下文转换。