假设我有一个4核CPU,我想在最短的时间内运行某个进程。这个过程在理想情况下是可并行的,所以我可以在无数个线程上运行它的块,每个线程花费相同的时间。
因为我有4个内核,所以我不期望通过运行比内核更多的线程来提高速度,因为单个内核在给定时刻只能运行单个线程。我对硬件了解不多,所以这只是一个猜测。
在更多的线程而不是核心上运行并行进程是否有好处?换句话说,如果我使用4000个线程而不是4个线程运行,我的进程会更快、更慢,还是在大约相同的时间内完成?
假设我有一个4核CPU,我想在最短的时间内运行某个进程。这个过程在理想情况下是可并行的,所以我可以在无数个线程上运行它的块,每个线程花费相同的时间。
因为我有4个内核,所以我不期望通过运行比内核更多的线程来提高速度,因为单个内核在给定时刻只能运行单个线程。我对硬件了解不多,所以这只是一个猜测。
在更多的线程而不是核心上运行并行进程是否有好处?换句话说,如果我使用4000个线程而不是4个线程运行,我的进程会更快、更慢,还是在大约相同的时间内完成?
当前回答
理想的情况是每个内核有一个线程,只要没有线程会阻塞。
在一种情况下,这可能是不正确的:有其他线程在核心上运行,在这种情况下,更多的线程可能会给您的程序更大的执行时间。
其他回答
大量线程(“线程池”)vs每个核心一个线程的一个例子是在Linux或Windows中实现web服务器。
由于在Linux中套接字是轮询的,因此许多线程可能会增加其中一个线程在正确的时间轮询正确的套接字的可能性——但总体处理成本将非常高。
在Windows中,服务器将使用I/O完成端口(IOCPs)实现,这将使应用程序事件驱动:如果I/O完成,操作系统将启动一个备用线程来处理它。当处理完成时(通常是请求-响应对中的另一个I/O操作),线程返回IOCP端口(队列)等待下一次完成。
如果没有I/O完成,就没有要做的处理,也没有启动线程。
事实上,微软建议在IOCP实现中每个核不超过一个线程。任何I/O都可以附加到IOCP机制。如果需要,应用程序也可以发布IOCs。
我想在这里补充另一个观点。答案取决于这个问题是假设弱缩放还是强缩放。
从维基百科:
弱伸缩性:对于每个处理器的固定问题大小,解决时间如何随着处理器数量的变化而变化。
强伸缩性:对于固定的总问题规模,解决时间如何随着处理器数量的变化而变化。
If the question is assuming weak scaling then @Gonzalo's answer suffices. However if the question is assuming strong scaling, there's something more to add. In strong scaling you're assuming a fixed workload size so if you increase the number of threads, the size of the data that each thread needs to work on decreases. On modern CPUs memory accesses are expensive and would be preferable to maintain locality by keeping the data in caches. Therefore, the likely optimal number of threads can be found when the dataset of each thread fits in each core's cache (I'm not going into the details of discussing whether it's L1/L2/L3 cache(s) of the system).
即使线程数超过内核数,这也是成立的。例如,假设程序中有8个任意单位(AU)的工作将在4核机器上执行。
案例1:运行四个线程,每个线程需要完成2AU。每个线程需要10秒来完成(有很多缓存丢失)。对于四个内核,总时间为10s (10s * 4个线程/ 4个内核)。
情况2:运行8个线程,每个线程需要完成1AU。每个线程只需要2s(而不是5s,因为缓存丢失的数量减少了)。如果是四核,总时间为4s (2s * 8线程/ 4核)。
我简化了这个问题,忽略了其他答案中提到的开销(例如,上下文切换),但希望您明白,根据您正在处理的数据大小,拥有比可用内核数量更多的线程可能是有益的。
希望这是有意义的,检查CPU和内存利用率,并设置一些阈值。如果超过阈值,不允许创建新的线程,否则允许…
如果你的线程不做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线程将花费更长的时间。这有很多上下文转换。
理想的情况是每个内核有一个线程,只要没有线程会阻塞。
在一种情况下,这可能是不正确的:有其他线程在核心上运行,在这种情况下,更多的线程可能会给您的程序更大的执行时间。